Messages

1831

MP Server / Re: tablespace for CMOD db2 tables

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

Justin, thanks for the reply.

What if I want to have my application group segment assigned onto a different tablespace, or I should say its own tablespace?

If Application Groups are ALREADY in their own tablespace, why would you want to mess with that?  What problem are you trying to resolve?  How does doing this (invasive and likely unsupported) configuration change help you?

-JD.

1832

MP Server / Re: db2sysc - High CPU utilization

« on: February 15, 2011, 04:27:37 AM »

There are lots of ways to create really insane queries -- check your System Log for queries that begin just before you start to experience the problem.

-JD.

1833

MP Server / Re: db2sysc - High CPU utilization

« on: February 12, 2011, 01:23:52 AM »

The most common cause of this is that someone, somewhere is doing a crazy query, like searching for a wildcard on string field with no index.

-JD.

1834

Other / Re: Creating a new System Log Application Group

« on: February 12, 2011, 01:22:12 AM »

I'm going to challenge your original assumption.  What makes you think you need a new Storage Set?  I can't think of a reason for this off the top of my head.

-JD.

1835

MP Server / Re: tablespace for CMOD db2 tables

« on: February 12, 2011, 01:20:02 AM »

CMOD should already be creating new tablespaces for each App Group segment.

-JD.

1836

MP Server / Re: Which TSM server version?

« on: February 10, 2011, 01:28:55 AM »

I recommend 5.5.x because TSM 5.4 is the recommended version for 8.4.x.  Using 5.5 (which is still supported and receiving fixes) is less risky than jumping to 6.2 at the moment.

The versions of requisites that CMOD is tested with are always available in the readme for that version.

The URL: ftp://ftp.software.ibm.com/software/ondemand/fixes/v840/8.4.0.3/readme.txt

For 8.4.0.3:

3. OnDemand Testing Environment
-------------------------------------------------------------------------------

  The following is a list of the environments in which IBM tested the
  latest Release/PTF.

        AIX:
           AIX    - 5.3
           DB2    - 9.1
           TSM    - 5.4

        HP-UX:
           HP-UX  - B11.23 (V11i V2)
           DB2    - 9.1
           TSM    - 5.4.1

        SunOS:
           SunOS  - 5.10
           DB2    - 9.1
           TSM    - 5.4

        Windows:
           Windows   - 2003 R2
           DB2       - 9.1
           TSM       - 5.4

        Linux:
           RedHat - RHES release 4 U4
                    Kernel (2.6.9 glibc-2.3.4)
           SuSE   - SLES 10
                    Kernel (2.6.16 glibc-2.4-31)
           DB2    - 9.1
           TSM    - 5.4

        Linux on System z:
           RedHat - RHEL release 5 U0
                    Kernel (2.6.18-8.el5 glibc-2.5-12)
           SuSE   - SLES 10
                    Kernel  (2.6.16 glibc-2.4-31)
           DB2    - 9.1
           TSM    - 5.4


You're probably better off doing a full upgrade (db2, TSM, CMOD) before implementing your switch to SSAM.  Why run the risk of upgrading to old bugs?

-JD.

1837

General / Re: Performance measurement

« on: February 09, 2011, 07:34:20 AM »

Very basically...

Real is actual time (ie, "wall clock")
User is time the process spent doing actual work
Sys is the time the process spent waiting for the system (i/o wait, paging, etc.)

Google for more detailed info.

-JD.

1838

MP Server / Re: TSM question

« on: February 09, 2011, 06:59:04 AM »

Restores without the original TSM database are unsupported (ie, there is no command to rebuild a server from data tapes only, because it would lack policy information).  Make sure you have multiple viable copies of your TSM database.  Consider having a half-dozen (non-WORM) tapes where you can write TSM DB Backups, or back up the TSM database into a filesystem and have that backed up by your enterprise backup solution, and restored to your DR box at the time you need to recover.

-JD.

1839

MP Server / Re: Which TSM server version?

« on: February 03, 2011, 01:33:17 AM »

I still recommend TSM 5.5 for now. 

For anyone considering upgrading, I've been advised to upgrade DIRECTLY to TSM 6.2, skipping the step to TSM 6.1.

-JD.

1840

MP Server / Re: ARSADMIN Unload VS ARSDOC Delete

« on: February 03, 2011, 01:31:44 AM »

I'm not sure that arsdoc would delete the underlying storage object, even if a load only has one object.  If someone's willing to test it out and report back, it would be good to know.

-JD.

1841

Other / Re: arsdoc delete

« on: January 29, 2011, 07:37:46 AM »

This solves one problem and creates another one -- table segments that are too small, leading to terrible query performance.

Garbage in, Garbage out.  You and your management need to push back and fix the data quality issues you're seeing.

-JD.

1842

MP Server / Re: image indexing

« on: January 29, 2011, 07:33:14 AM »

Unless I missed something, the load error doesn't seem to point to a missing System Log.  He may need to check the db2diag.log file, or the event viewer for more information on the error that is preventing loading.  Let us know what you find, Vaios.

-JD.

1843

Documentation / Re: Versions available for CITRIX

« on: January 29, 2011, 07:28:52 AM »

You may be able to USE the old software with Citrix, but it is not SUPPORTED.

Support for Citrix begain with version 8.4.1.0.

-JD.

1844

General / Re: CMOD Vs Filenet/Documentum/LiveLink

« on: January 29, 2011, 07:25:06 AM »

CMOD uses compression that spans documents to get better compression than any of these solutions could ever get.
CMOD has the ability to process millions (maybe even billions) of documents per day, and STILL serve end users.
CMOD is tamper-resistant -- it would be extremely difficult to tamper with a document and not have it be easily detected.

For what CMOD is (an archive and retrieval system) it is the best.  If you need BPM, it is possible to integrate Filenet P8 with CMOD.

1845

MP Server / Re: SSAM and arsload

« on: January 25, 2011, 10:06:56 PM »

The behavior is the same if you were relying on Write-Once optical disks.  If segments of the data are written out to disk, then the load fails, you've just wasted that space for the duration of the retention period configured in SSAM.

Hopefully most of your failures occur during indexing, which means there would be no loss of storage.

-JD.