Messages

1591

MP Server / Re: DB2 9.7 Question - second storage path

« on: February 27, 2013, 07:20:37 AM »

In CMOD, the plan would be that you define SMS filesystems inside the ars.dbfs configuration file, then create the database.

Can you not just define new tablespace containers on the new filesystems?

-JD.

1592

MP Server / Re: Need to move TSM volumes to new Disk

« on: February 25, 2013, 01:06:41 PM »

That's not something anyone is likely to be able to write 'blind'. 

You can learn about 'for' loops in bash and ksh (UNIX shell scripting languages) to help create multi-line scripts.  You put the names of the volumes in a file, then use the 'for' look to iterate over each volume name, then print the command you want to run with the echo command.

-JD.

1593

Report Indexing / Re: Embedded Resources in AFP file

« on: February 22, 2013, 09:09:54 PM »

There are a bunch of options you can use to the RESTYPE parameter.  "ALL" strikes me as the one you might want to use...

In the CMOD 8.5 for multiplatforms Indexing Reference, you can find the RESTYPE parameter in Chapter 3 (Page 86 in the version of the doc I have) to get the scoop.

The information center link to the options is here:
http://publib.boulder.ibm.com/infocenter/cmod/v8r4m1/index.jsp?topic=/com.ibm.ondemand.indexingmp.doc/ars1d171213.htm

-JD.

1594

z/OS Server / Re: CMOD for z/OS 7.1 and using PDF indexer

« on: February 22, 2013, 10:37:03 AM »

This holds true for all non-windows platforms.

If you have a large volume of PDFs to load, you'll want to integrate CMOD on Windows with the PDF Indexer into your environment.  It's not an answer I like, but it's the best answer at the moment.

-JD.

1595

Report Indexing / Re: arspdoci taking unusually long time.

« on: February 21, 2013, 07:10:33 AM »

Try running your load command from a windows PC and let us know how much faster it is. 

-JD.

1596

Report Indexing / Re: arspdoci taking unusually long time.

« on: February 19, 2013, 07:54:17 AM »

arspdoci is known to be slow on non-Windows platforms.  A number of other CMOD sites have integrated a Windows indexing server into their solution for processing large volumes of PDFs.

-JD.

1597

MP Server / Re: Recommendation: DO NOT upgrade to 8.5

« on: February 16, 2013, 06:55:39 AM »

Yeah, by keeping clients at 8.4.x, you continue to use the old authentication method, which doesn't require a call to the GSKit.

-JD.

1598

MP Server / Re: migration DR550 to new hardware

« on: February 15, 2013, 06:41:58 AM »

Hi Michael.

An object server is different than TSM.  Back in the day, when dedicated leased lines were slow (and expensive), the architecture of CMOD allowed for multiple 'object servers' to be geographically diverse, without having to send gigs of data over slow connections -- instead, the data was loaded into a 'local' object server with it's own cache and optionally TSM storage, and index data was sent over the wire to the library server.

Today, that doesn't make much sense, given that network connectivity is exceptionally fast, and relatively affordable.

So, your standalone TSM server doesn't really count as an 'object server' in the CMOD definition, even though it's a server filled with objects. 

-JD.

1599

MP Server / Re: ARSADMIN DECOMPRESS - Large Objects

« on: February 15, 2013, 06:34:28 AM »

I tried this long ago, and it sticks in my mind that you had to have all the pieces of the object (FAAA -FAAZZ, etc) in order to get it decompressed properly, otherwise arsadmin decompress gets stuck in an endless loop.

1600

MP Server / Re: WARNING - ARSDOC GET -X <loadid> issues

« on: February 15, 2013, 06:32:44 AM »

Is that to say that the source of the index values when running 'arsdoc get' is the *FAA1 file, and not the database table when using the -X parameter? 

-JD.

1601

MP Server / Re: Multiple arrsockd license servers?

« on: February 15, 2013, 06:21:46 AM »

Yup, my customer confirmed that it was related to logging -- I think they had started CMOD under the archive ID, but the owner of the arslog exit was root -- and the archive user didn't have execute permission, so it failed at the OS level, causing strange behaviour in arssockd.

1602

MP Server / Re: Recommendation: DO NOT upgrade to 8.5

« on: February 15, 2013, 06:19:33 AM »

Hey Steve.

I'm not seeing this in every site either, but the sites that have the problems are seriously affected by it, and as I mentioned, the workaround isn't 100% effective.  The GSKit bug apparently only affects "some" Power processors.  In one site, the DR system is performing perfectly -- but the production system occasionally takes 4 minutes to load a single TIF check image, and processes the next one in 0.7 of a second.

Any insight or advice you have on this bug would go a long way to helping restore my confidence in v8.5.

-JD.

1603

OD/WEK & JAVA API / Re: Can bugs in Java apps cripple a CMOD server?

« on: February 13, 2013, 06:10:40 AM »

I implemented it, and it didn't resolve the issue to my customer's satisfaction -- in some cases it made the situation worse.

That's why I've recommended large installations (who are at a previous version like 8.4.x or 7.1.2.x) to avoid 8.5 -- or at the very least do considerable testing to see if they're affected.

-JD.

1604

MP Server / Re: Upgrade from 7.1.2.6 to 9.x

« on: February 12, 2013, 05:23:28 AM »

So it sounds like you need at least ONE stop at CMOD 8.x before you can move on to v9.  Good to know!  Thanks!

-JD.

1605

MP Server / Re: Upgrade from 7.1.2.6 to 9.x

« on: February 11, 2013, 11:51:36 AM »

I suspect you'd have to stop at CMOD 8.5, upgrade the tables, then move on to CMOD v9.

Let us know what you find out!

-JD.