Messages

1951

MP Server / Re: OD Query Restriciton

« on: February 07, 2010, 09:45:11 AM »

Query restrictions aren't so much about denying access to documents as it is never showing them the ones they can't access.  Your auditors are probably looking for a 'smoking gun' of a user who tried to access something and was denied -- this doesn't happen, because the documents they're restricted from opening are never displayed in the hitlist.

If you need to provide SOMETHING to the auditors, show them the query restriction and the list of users who are subject to it.  This is especially useful if the query restriction is written as "branchno=1234" instead of "branchno!=5678" -- the first selects ONLY what they can see.  The second prevents them from seeing something, but allowing everything else.

When writing query restrictions, I try to write them in such a way that "That which is not expressly permitted is forbidden."  That's how my friends describe driving in Montreal. 

Good luck with the audit!

-JD.

1952

Other / Re: Most Popular Platform for CMOD

« on: February 02, 2010, 05:53:48 AM »

The only people who would know for sure would be IBM.

I would hazard a guess and say it's AIX -- because it was an AIX-only product for the first few years of its life.

While I personally recommend the combination of AIX/DB2/TSM/CMOD (I call it "One-Stop-Shopping for Blame when something goes wrong") there are lots of large systems (1TB+) on all the platforms.  It's less about the platform, and more about managing it properly.

-JD.

1953

MP Server / Re: Use of mulitple cache

« on: January 07, 2010, 01:21:00 PM »

Hi Walt.

There's only one cache on the Multiplatforms version of CMOD -- even though it can consist of multiple filesystems.

It sounds like you're creating Storage Sets for new Application Groups -- which is something that I recommend as a best practice for CMOD Admins.  I usually suggest that each Storage Set have it's own node in TSM as well, but it doesn't sound like you're doing that.  (Although, I don't think defining Storage Sets in this way prevents you from adding a TSM node later on.)

Honestly, I'm a little fuzzy on exactly what you're doing and why.  If you can fill us in a little more on what you're doing (and trying to achieve), I'd greatly appreciate it. 

Happy New Year!

-JD.

1954

z/OS Server / Re: Minimum Folder Length - CICS folder search

« on: December 22, 2009, 12:11:34 PM »

I was under the impression that the newer versions of CMOD with DB2 used 'fetch first X rows only' and used this clause inside the optimizer to minimize the impact of large queries.  I'd try and investigate why CMOD isn't behaving this way on your system.

Since you're already using all of my other recommendations, I hope IBM can find/create a solution that fits your needs!

Take care...

-JD.

1955

z/OS Server / Re: Minimum Folder Length - CICS folder search

« on: December 22, 2009, 09:53:59 AM »

Hi Michael.

In the multiplatforms world, there are a few ways you can prevent sillyness like 14-billion-row-queries.

The simplest is simply limiting the number of queries that are returned.  In the Admin client, open up the Folder, choose the permissions tab, and fill in the 'Max Hits' box with an appropriate number.

The next easiest is by inserting a default date range that you think will satisfy MOST user requests, without hitting your CPU too hard.  In the Admin Client, open up the Folder, go to the 'Field Information' tab, select the date field you've chosen as your segment date (check the AG definition if you're not sure) and put in some defaults.  You can use 't' for 'today' and t-90 to signify '90 days ago'.

The complicated one is writing a query restriction.  In the Admin Client, open up the group that the users belong to, and under the 'Application Group Permissions' tab, choose an Application Group from the 'selected' box, and write some SQL that limits people's access based on any database field or condition that you can access in SQL.  You can use the query restriction field to separate people out by offices (branch = 123) or to specific geographies (zipcode between 12345 and 54321), etc.

Hope this helps, have a great holiday!

-JD.

1956

Other / Re: New application version, naming

« on: December 16, 2009, 10:13:41 AM »

Hi Pasi.

One of the things I cover in my 'Best Practises' presentation is that Application Groups should ALWAYS be defined as having multiple Applications.  The primary reason for this is "versioning".

For example:

I create an AG today, with a AppID field defined as a small integer.  When I define the primary Application, I give it a value of '1'.  Several days/weeks/months/years later, a change to the input data is made.  Instead of modifying the index parameters, I simply copy the Application, give it the number '2', and modify the indexer parameters.  If I need to keep data loading automatically with arsload, I can rename the PREVIOUS Application to 'App-v1' and the NEW Application to just be 'App' (or whatever the Application name needed to be.)

I know this is a tricky concept -- I hope I've explained it clearly. 

If the current Application Group you're working on isn't configured for multiple Applications, you'll need to change the existing App in place, and maybe comment out the old indexing parameters.  (You should have plenty of space for this -- the indexing parameters can be up to 32 kilobytes in size -- over 32,000 characters!)

Hope this helps!

1957

Other / Re: monitoring DR550

« on: December 16, 2009, 09:25:37 AM »

Hi Michel.

It's true that a DR550 is basically an AIX Server with TSM.  There are ways to obtain root access on the system so that you can install software -- but you'll want to verify with IBM that what you're attempting will be supported.

Many years ago, I had discussions with the DR550 team about what is POSSIBLE versus what is SUPPORTED -- it was enlightening, but certainly not encouraging.

If you decide to go ahead, please don't forget to keep us in the loop!

-JD.

1958

MP Server / Re: Co-Existence of CMOD old & new versions

« on: October 21, 2009, 02:16:03 PM »

John was interested in having me elaborate about running CMOD inside virtual machines because IBM says they don't support them.

There are still advantages to be gained from running your development, test, quality assurance, or user acceptance testing regions inside virtual machines.  I personally run CMOD on Linux inside VMs (on my Mac!) for testing -- or particularly when I'm extracting data from other CMOD servers.

For the record, running CMOD inside IBM's Logical Partitions (LPARs) *is* supported -- so it might have less to do with virtualization technology, but WHOSE virtualization technology you're using.   

-JD.

1959

iSeries / Re: Access Storage Attached zOS Mainframe From AIX CMOD

« on: October 15, 2009, 03:57:53 AM »

Hi Victor.

CMOD can use a TSM server anywhere on the network.  I've set up more than one CMOD installation that used the pre-existing enterprise backup system running TSM to archive data from CMOD.  IBM even sells a hardware solution (the DR550) that does exactly this sort of remote-TSM storage.

Consider the following:

• Backup & Archive are different, and need to be configured as such.
• Network latency will kill performance if you plan on doing a lot of retrievals or using migrate-on-load.
• The best defence against deteriorating performance is proper caching with fast local disk.
• Retrieval schedules don't match backup schedules.  Be prepared to retrieve anything, anytime.

Good luck!

-JD.

1960

MP Server / Re: Hyphen in OutSize message

« on: September 25, 2009, 07:49:09 AM »

Hi.

First and foremost, you *really* need to apply some patches.  7.1.2.0 has a number of serious bugs.

The input size is probably unknown because you're using a generic index.  OnDemand doesn't calculate the size of documents to be stored when you're using a generic index.

The negative number you're seeing is an 'overflow' -- it's a problem that's fixed in the newer versions of CMOD.

-JD.

1961

iSeries / Re: How do you add a report via the Load ID

« on: August 21, 2009, 08:22:36 AM »

I'm not sure if it works the same way on the iSeries, but in the Multiplatforms world, this is fairly straightforward:

You can retrieve a loaded file using the "arsdoc get" command -- specifically, use the -X option and specify the load ID in order to get the actual document back. 

Once you have the data extracted, you can reload it into the new Application Group with arsload.

You can find the complete documentation for arsdoc in the Administrator's Guide.  (For CMOD Multiplatforms v8.4.1 -- it starts on page 245.)

Hope this helps!

-JD.

1962

MP Server / Re: DB2 Internal tables ARS.....

« on: August 21, 2009, 07:53:18 AM »

Hi Stephane.

Look a little more closely at Chapter 3 in the CMOD Redbook (the one I have is from January 2008).

If you have any specific questions, don't hesitate to ask here.

-JD.

1963

MP Server / Re: Co-Existence of CMOD old & new versions

« on: August 06, 2009, 07:38:29 AM »

Hi Sandeep.

In short, no.

While you can have multiple versions of DB2 installed at the same time (/opt/IBM/db2/v8 and /opt/IBM/db2/v9) CMOD doesn't support this by default.  Additionally, different versions of DB2 require their own databases, as there are modifications to the database format between versions.  A similar problem exists for CMOD if you're using substantially different versions where changes were made to the system log or CMOD's internal tables.

There's also a drastically increased potential for human error -- if the wrong command is run on the wrong version of CMOD against the wrong DB2 instance, you can mangle the database or cache filesystems associated with it.

Your best bet is to use virtual machines (CMOD on Linux running in a VM on a PC) or Logical Partitions (LPARs on AIX).

-JD.

1964

MP Server / Re: Multiple TSM Servers

« on: May 30, 2009, 02:42:55 AM »

Hi Walt...

I believe that the only supported configuration where you use multiple TSM servers is when you use multiple object servers -- something I recommend for only the largest of installations.

With high-speed data connections becoming ubiquitous, a substantial rationale for separating object and library servers in CMOD has disappeared.

If you tell us what your problem or concern is, maybe we can suggest an alternative.

-JD.

1965

MP Server / Re: How Do I Migrate Indices & Objects

« on: May 22, 2009, 04:55:45 AM »

Hi Walt.

The single major drawback to not using TSM is a complete loss of flexibility in storage management.

Without TSM, you can't:

• Migrate unused or infrequently accessed data to cheaper storage.
• Handle an influx of historical data from a merger or acquisition.
• Utilize tape or optical to store data that is literally never accessed.
• Provide for 'higher availability' than just using disk-based cache.

Here's two examples of the costs of not using TSM:

1)  A large financial services firm stored a particular type of extremely-high-volume documents for 90 days in cache.  When a customer sued them, the court mandated that NO DATA was to be deleted from the system for the duration of the case.  The volume of documents balooned, quickly filling their available disk.  They were adding 1TB of cache every three to four months, costing hundreds of thousands of dollars to purchase the additional disk.  (Nevermind the cost of operating it -- floor space in the datacenter, electricity, and cooling.)  Configuring the Application Group with TSM from the start would have allowed them to migrate this data off to tape where it would comply with the court order, but cost hundreds of dollars, not hundreds of thousands of dollars.

2)  A health care firm was using CMOD in a cache-only environment.  In the middle of the day, a technician re-zoned disks on the SAN, and wiped out disks on a handful of servers, including some of CMOD's cache filesystems.  With TSM and a directly connected tape library, (and some help) they would have been able to re-populate the cache from the TSM tapes.  Without TSM, they suffered a 48h outage while tapes were pulled from their offsite location, and queued up behind the other systems that were damaged, and finally restored.

In summary, TSM is AWESOME, and anyone using CMOD for archival purposes should be using it.   

-JD.