Messages

1846

z/OS Server / Re: you know a possibility to change the segment field in the application group?

« on: January 21, 2011, 02:03:03 AM »

Hrm.  If I understand correctly, you have ONE segment field, and it can contain EITHER the 'business' date, or the 'technical' date, which makes searching for a particular document difficult.

If I understand your problem correctly, the best recommendation that the two dates be stored separately, so that a user can search on the field of their choice (either 'business' or 'technical' date).

If that's not possible, I'd increase the range of the default query to cover a range of dates that would catch BOTH dates, or require that an additional field (something that is 'mostly unique') be queried at the same time, and add an index to that field.

Of course, this means you're doing MORE work, not LESS work (like you originally asked).

If this can't be solved simply, I'd start looking carefully at ways to optimize your database performance to make the queries move a little more quickly.

1847

Report Indexing / Re: Indexing files containing DBCS (Double-Byte Character Set)

« on: January 21, 2011, 01:55:26 AM »

Even if you get past that issue, I don't think you'll be able to store those double-byte index values inside your database without switching it to UTF-16.  That's something I run into constantly during migrations.  Non-ASCII characters get converted to double-byte strings, meaning they won't fit inside the columns defined in databases with 8-bit codepages.

The icing on the cake is that I have no idea how this would affect searching.  (Can a Windows client or web browser properly convey double-byte characters and make it all the way through CMOD down to the database for a query?)

Hopefully some of our users from Europe will be able to help with this.

-JD.

1848

MP Server / Re: Overlays/Pre-printed forms in CMOD

« on: January 21, 2011, 01:50:22 AM »

If you store the AFP resources (PDEF, FDEF, OVLY, FONT) at load time, you're guaranteed to get the maximum document fidelity.

Is it possible to change AFP documents stored in OnDemand?  I'll just say that it's extremely difficult, and successfully changing a document would be easily detectable after the fact.

I'm not sure what you mean by PPF.

-JD.

1849

MP Server / Re: Copy documents from archive storage to cache storage.

« on: January 21, 2011, 01:46:05 AM »

Sandeep...

I've looked at the -m parameter, and it must be used in conjunction with the store or retrieve commands -- it doesn't repopulate the cache from secondary storage by itself, which is what Pankaj is looking for.

I haven't tested the latest versions of CMOD, but the problem with this method (again, in the past) has been that it places older documents back into the cache with expiration dates that don't take into consideration the age of the document -- you end up with a 'bulge' of documents that sit in the cache for weeks, months, or even years past their proper expiration date.  This makes your cache filesystem larger than it needs to be, and robs your other App Groups of storage that could be put to better use.

-JD.

1850

MP Server / Re: Overlays/Pre-printed forms in CMOD

« on: January 20, 2011, 07:50:54 AM »

Really, nothing in CMOD should be 'rebranded' or altered.  That affects our collective ability to rely on the data in CMOD as a high-fidelity, tamper-proof archive.

That having been said, laws might be different around the world, but I'm fairly certain that tampering with data (even if it's just cosmetic) renders it inadmissible in court.

-JD.

1851

MP Server / Re: Checking for an empty file.

« on: January 20, 2011, 07:28:21 AM »

As always, another great response from Alessandro.  I agree with everything he's written! 

Using arslog is the way to go when it comes to real-time monitoring.

-JD.

1852

MP Server / Re: Copy documents from archive storage to cache storage.

« on: January 20, 2011, 07:23:54 AM »

Hi Sandeep.

I don't think I've ever seen arsmaint -m (cache migration) re-populate a cache filesystem.  Can you point to the documentation or technote that describes this behaviour?  I'd be interested in testing that out.

-JD.

1853

z/OS Server / Re: you know a possibility to change the segment field in the application group?

« on: January 20, 2011, 07:21:06 AM »

I'll also make a request for more information.

What do you mean by 'Sometimes the segment field is bad'?  Is the incoming data incorrect?  Is the query for that data causing problems?
What exactly do you want to change, and what are you hoping to achieve by it?

-JD.

1854

Other / Re: Multiple Application Groups in a Folder

« on: January 15, 2011, 04:18:30 AM »

Simply set the default search range to something reasonable like 90 days -- CMOD will only search the tables that have records for those dates in them.  If the user doesn't find what they're looking for, they can expand the search window.

-JD.

1855

Other / Re: Loading Future Dates

« on: January 15, 2011, 04:16:21 AM »

Hi Guys.

That sort of data validation doesn't belong in CMOD.  It belongs upstream, where the data is generated. Failed loads create a bit of a mess - they are exceptions that must be handled manually by an administrator, and they create a failure messages in the System Log, and waste CPU time and I/O.  If you have a data quality issue, that needs to be addressed where the data is created.  CMOD is an archive -- the ultimate long term storage facility for documents, not a data validation tool.

As a very last resort, I'd consider writing a script on the server to test the data before handing it to CMOD, but really your management should be pushing back on the source of the data to perform proper validation.

-JD.

1856

MP Server / Re: Creating another Index - AIX DB2

« on: January 06, 2011, 06:44:34 AM »

Gotcha.  And yes, it doesn't sound like this will help you at all.

I've wagged my finger at web app developers many times over the years for not knowing even the most fundamental basics about querying databases.

When it comes to CMOD, the golden rules are:

1)  ALWAYS restrict your search with a narrow date range, like, oh, I don't know...  the number of days the docs are kept in cache?
2)  ALWAYS search for a 'mostly-unique' value like customer number which is indexed in the database.  (And not, for example, zip code.)
3)  ALWAYS maintain a persistent connection for high-volume apps -- ie more than one query/minute at peak times.

There are others, but these are the big ones.

Good luck with your upgrade!

-JD.

1857

MP Server / Re: Reload AFP Data

« on: January 06, 2011, 06:34:56 AM »

Hi.  Sorry I'm late to the game here. 

Pankaj is right on both counts about cache expiration -- historically, cache expiration was set at load time -- to make maintenance fast and easy by simply deleting directories that contained data that should have expired.  Of course, CPU power and IO bandwidth have improved dramatically, making this method obsolete.  Today, and  for a few years now, CMOD has been inspecting the contents of the cache and determining what is due to be expired based on the CURRENT cache expiration settings in the OnDemand Client.

The same applies for DB2 index expiration.  When configured properly, CMOD will expire records based on the CURRENT settings of the Life Of Data And Indexes parameter.

Maybe we should make a guide of FAQ for this topic.     Does anyone else have any questions (or information to share?) about extending retention?

-JD.

1858

MP Server / Re: Enhanced Retention Management

« on: January 05, 2011, 06:29:58 AM »

I can't seem to find anything but two lines of information on installing ERM in the latest InfoCenter.  Which, when you think about it, is probably sufficient -- creating and removing holds are done at the client level, and those processes are described inside the online help for the client.

Was there something specific that you were looking for?

-JD.

1859

MP Server / Re: TSM and expired documents

« on: January 05, 2011, 06:22:23 AM »

Hi Michel...

I can't really confirm anything that has to do with your server -- I don't know what software versions you're on, or precisely how it's configured.

What I *can* tell you is that the more recent versions of CMOD work more like the way you'd want them to -- expiring data based on the CURRENT expiration information, rather than the expiration information that was in effect at the time data was loaded.

Happy New Year, and good luck!

-JD.

1860

MP Server / Re: Creating another Index - AIX DB2

« on: January 04, 2011, 04:23:49 PM »

It might not have been clear from the sample code Stephen provided, but you'll need to run that 'create index' command for each table with AG data in it.  Not only will this take some time, but it'll use more disk space. 

If the field you've added is particularly large, or there are many (hundreds of millions or billions) of them, be prepared to see a substantial growth in your database.

Is there a reason you're stuck at 8.3?

-JD.