Messages

1756

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

« on: December 16, 2011, 06:53:29 AM »

I know that you're using iSeries, but hopefully the process for sending an eMail from the server is similar to UNIX/Linux.

First, once you retrieve the file, it needs to be in a format that the customer can view it in.  For most companies, this is PDF.  You could also convert to GIF, JPEG, or BMP if those options are desirable.  Once in the PDF format, you'll need to convert it so that it can be sent in an eMail - normally using MIME base64 ( http://en.wikipedia.org/wiki/Base64 ).  After that, format your eMail ("Dear customer, here's your invoice.") and append the converted file.

It will take some trial and error, but it's entirely possible.

The only other thing to be aware of is that your mail server needs to be properly configured.  If I had a dime for every time an automated eMail is rejected from my server (because the remote server is misconfigured, and looks like a spammer) I'd be eating a steak dinner every night!

Good luck!

-JD.

1757

Other / Re: Data Encryption CMOD MP and DB2

« on: December 15, 2011, 08:14:26 AM »

I've played with Vormetric once a very long time ago -- it basically encrypts all files at the I/O level.  So, you go to read a file, Vormetric intercepts that I/O call, and decrypts the data on the fly as it's read into memory.  Same thing happens in reverse -- perform a write, it's intercepted, encrypted, and the scrambled data is written to disk.  Of course, there's a performance penalty for this.

In the case of Steve's original item...  I suspect the performance hit would have been because of the massive number of I/O's that need to happen when doing cache management -- but I'd hope that may have been mitigated in a more recent version of the Vormetric product. 

Rich, I think the only way to get an acceptable answer to this question will be to get an evaluation version of Vormetric, and try it out for yourself.

-JD.

1758

MP Server / Re: Anyone doing PCI with CMOD?

« on: December 13, 2011, 08:08:16 AM »

For what it's worth, cache data is unreadable on devices due to IBM's proprietary compression method (OD77).  It's not encryption, but it's certainly serious obfuscation.  Between that and striping data across hard drives, you'd have to be up against a seriously committed adversary who was extremely well funded and equipped.

In all seriousness, it's easier, (and probably faster) to just try and crack login passwords with a brute force methodology.

1759

MP Server / Re: Tablespace: SMS vs. Automatic Storage

« on: December 09, 2011, 06:50:57 AM »

Hi Ali...

It sounds like your DBAs are chasing a feature for the sake of using it.  Your databases sound small from what you say (50 million rows -- some customer load three times that volume every month!), and finding space to store that much data shouldn't be an issue on modern hardware.  I have customers running CMOD on hardware that is 10+ years old, and they have hundreds of millions of rows -- and while they wish database backups ran faster, it works for them.

It sounds like you've answered your own question.  Performance isn't a problem, and your databases aren't large enough to warrant using a new database feature that's unsupported by the application that uses it...  Unless the DBAs can show a real, measurable, and substantial benefit to using this feature, there's really no point in going further down this road.

1760

MP Server / Re: Active/Active CMOD Configuration

« on: December 08, 2011, 08:26:19 AM »

It's been a while since I set this up, but it basically involves setting a series of triggers that find annotations, the record on the opposite machine, and duplicates the annotation.

1761

MP Server / Re: Tablespace: SMS vs. Automatic Storage

« on: December 08, 2011, 07:21:55 AM »

Just a few things from your three posts...

AIX 5.3.x is going out of support in April 2012.  You may want to select a newer version of AIX to implement on.

CMOD 8.4.x is going out of support in Sepember 2012.  Again, you might want to choose 8.5.

You didn't mention why you're trying to change the way your database runs -- are you experiencing performance issues?  Is growth a problem?  Are backups taking too long?

You also didn't mention the size of your system -- how many GB/TB/PB are you storing, and how many rows would you say you're storing in DB2 today?

I haven't looked into 'automatic storage' in DB2 yet -- probably because none of my customers (even the extremely large ones) are running into disk-IO based bottlenecks.  Why are you looking at this feature specifically?  Are you running into performance problems during queries or loads?

I'm sorry to have more questions than answers, but the more background information you give us, the better answer you'll get. 

-JD.

1762

MP Server / Re: Active/Active CMOD Configuration

« on: December 04, 2011, 01:01:22 PM »

It's possible to replicate Annotations across sites.

1763

MP Server / Re: ARSMAINT usage

« on: December 02, 2011, 01:50:24 AM »

Hi Walt.

You'll want your local DB2 DBA to take a peek at your database configuration to see if there are opportunities to improve performance (IO Cleaners, etc.).

I'm not sure which version you started with, but newer versions of CMOD do better checking for the eligibility of files for expiration (specifically, not deleting files that would normally be ready for cache expiration due to extended cache retention in the AG config).

It's likely that your only real choice is to extend your outage window.

-JD.

1764

MP Server / Re: Active/Active CMOD Configuration

« on: December 01, 2011, 02:44:07 AM »

I recommend the configuration that Russell is using. 

1765

Other / Re: Deleting Volumes from a TSM STGPOOL

« on: November 30, 2011, 02:48:04 AM »

If I remember correctly, your storagepools were created with 'snaplock' deletion protection.  Unless you're talking about something else, those volumes can't be deleted until they expire naturally.

1766

MP Server / Re: What bit in the MASK field on the ARSAGFLD represents the Expire Date checkbox

« on: November 30, 2011, 02:44:49 AM »

The values of this specific field has changed in the past as CMOD has added new features (and decommissioned older features).  I don't recommend relying on this field for day-to-day operations.

However, the information you're looking for is in bit 5 (counting from the right).

-JD.

1767

MP Server / Re: Active/Active CMOD Configuration

« on: November 30, 2011, 02:37:06 AM »

I can't imagine a design where you have two active CMOD servers sharing a single DB2 database.  That eliminates any benefit you have to running redundant hardware -- which is usually the least likely piece of the architecture to fail, really.

Most active-active architectures are entirely separate.  Different instances, running different databases, storing on different disks, hosted on separate servers, living in separate data centers.

How are you tying these two servers together?

-JD.

1768

Other / Re: Deleting Volumes from a TSM STGPOOL

« on: November 29, 2011, 04:09:20 AM »

Volumes will get deleted automatically when the data within them expires.  Why do you need to override that?  You risk deleting real data.

1769

Report Indexing / Re: Page break on CSV

« on: November 19, 2011, 03:30:32 AM »

Wouldn't that break the CSV file format?

It sounds like you're storing this CSV file as text.  Why not store it as a user defined data type, and let users open the CSV file in a spreadsheet?

-JD.

1770

Other / Re: TSM MAXSCRATCH

« on: November 10, 2011, 05:00:08 AM »

Set it to the number of blank tapes you have in the library.  So, it sounds like you used 100 tapes.  If you added 100 more slots to the library and added 100 more blank tapes, you'd increase the number to 200.

-JD.