Messages

1861

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.

1862

z/OS Server / Re: Multiple System Logs

« on: December 27, 2010, 08:39:09 AM »

I've seen this before in the Multiplatforms version.  I used arstblsp to close the open tables, then let CMOD create a new one.  I'm not sure if this happens by design, but I figured it was very unusual -- but after closing the two tables, the problem that was being experienced went away.

-JD.

1863

MP Server / Re: CMOD 8.4.1 Query Caching

« on: December 26, 2010, 07:08:37 AM »

Hi Trambak.

The whole idea of Query Caching depends on your database engine.  CMOD has no built-in functionality for that.

There are a few ways that data can be cached that aren't specific to CMOD though.

Inside DB2, there is a 'Query Optimizer' that spends CPU cycles trying to find the fastest way to service the query you're executing.  The result of this optimization is cached.  Therefore, if you run the same query again (even with different criteria) you'll get the quickest 'path' to the data, but without burning the CPU to determine that optimal path.

Also, if the 'second query' happens closely enough to the first, the database pages for the index and table might still be in memory, making it faster the second time, since the database wouldn't have to pull the pages from disk.

And finally, the operating system or disk storage subsystem may have additional caching that keeps recently accessed data in memory.  This may also make a second query faster than the first.

However, with all of that being said, ALL queries should be coming back in a 0.1 seconds, or preferably less.  If you aren't seeing this level of performance, you need to (in order of difficulty)... change your indexing parameters, tune your database, improve your I/O, or upgrade to new hardware.

Hope that helps!

-JD.

1864

MP Server / Re: Load ID description

« on: December 22, 2010, 07:35:38 AM »

Of course! 

If your segment date field is a date & time field, those numbers will be MUCH larger and represent the number of seconds since January 1st, 1970.

-JD.

1865

MP Server / Re: Load ID description

« on: December 15, 2010, 07:53:19 AM »

1234 - Application Group ID.
1 - Primary Storage Node
0 - Secondary Storage Node (unused)
1FAA - "Base" Object name
2342 - earliest ("minimum") date in the load.
3564 - last ("maximum") date in the load.

Hope this helps. 

-JD.

1866

Other / Re: Integer and Small Integer in Application Group

« on: December 08, 2010, 07:05:02 AM »

Hi Russell.

Integers are "smaller" to store in the database (four bytes in a 64-bit number which can hold a ridiculously large value, versus storing say, a social security number with 11 bytes as a string), which is why dates are stored numerically inside CMOD. 

There are consequences for searching too.  At the very lowest level, comparing integers is a single-step operation for most CPUs.  Comparing strings can take as many steps as there are characters in your field.  Thankfully, today's modern CPUs can do either function in the blink of an eye.

The problem comes down to searching & format.  You can't store the (sometimes expected) hyphens when you store 'formatted' numbers (like a SSN), but you can strip them out at load & query time, and depending on the situation, insert them back in when they're displayed.

When I'm making the decision, I try to think about how people will use the information in the field.  If they're likely to do numerical functions on the fields (query records with Account Balance greater than $100, calculate sum of OverdraftAmount field) then I use an integer.  If there might be queries for string-based wildcards (all account numbers containing "456") then I store the formatted string.

Good luck!

-JD.

1867

z/OS Server / Re: converting system log timestamp integer field

« on: December 08, 2010, 06:47:26 AM »

ewirtz has it right -- if you want the date in DB2's internal date format.

The 10 digit number you're seeing is the number of seconds since midnight on January 1st, 1970, exclusive of time zone information.  This is how time is measured on UNIX systems.

You can get the number of days since January 1st, 1970 by dividing by 86400 (the number of seconds in a day).  You can use this value (or the 10-digit integer) to feed into arsdate, and get a date and time, adjusted for your current time zone.

Hope this helps!

-JD.

1868

MP Server / Re: How to find the load-id for those appl group with expire by segment

« on: December 04, 2010, 10:43:18 AM »

Depending on the type of documents you load, you might get multiple Load ID's.  You can find all of the Load ID's associated with a particular load inside the message text associated with the load record in the System Log.  Just double-click on the record.

-JD.

1869

Other / Re: Adding new Index field to and exisitng large Application

« on: November 16, 2010, 02:18:20 PM »

If I understood the way Greg explained this at the ODUG conference, the field should be added to new tables on a going-forward basis, there should be little to no waiting -- but the field won't exist for earlier tables.

-JD.

1870

MP Server / Re: Page Count

« on: November 16, 2010, 02:14:46 PM »

You have to use ACIF to get page counts, unless the process that's generating the data can also provide it to your generic index file.

-JD.

1871

MP Server / Re: Max report size.

« on: November 16, 2010, 02:13:32 PM »

It would certainly make sense to use Large Object Support for this report, and index it with ACIF.  Nobody wants to retrieve or view 250,000 pages at a time.

-JD.

1872

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

« on: November 16, 2010, 04:38:03 AM »

In most situations, you just suffer through it until the cache starts to be populated with new data -- each day that you load new files, your system gets a little faster as more and more information is loaded into the cache filesystem.

It is possible to retrieve documents from TSM, and then place them back into the cache.  I've written a utility to do this for customers to resolve performance problems created by poor caching -- situations where administrators who selected 90 days for caching, but users were accessing documents for 450 days.  arsadmin can perform this task, but I've found that it doesn't preserve expiration dates in the cache, so it creates a bigger mess than it really solves.

-JD.

1873

z/OS Server / Re: At what size of file it's necessary to use large object in CMOD?

« on: November 16, 2010, 04:28:49 AM »

You only want to use large object support when your individual documents have THOUSANDS of pages.  Large object support makes accessing those types of documents faster by not requiring that you retrieve ALL the pages at once.

There is no advantage to using Large Object Support when you are not storing thousands of pages.  It actually makes your system LESS efficient for small documents.

I would check to make sure you've got the right parameters defined for your document type in the Application -- there are very few situations where you should be running out of memory. 

Also, check the README documents for more recent versions of CMOD to ensure that you aren't encountering a bug in the software.

Feel free to post more diagnostic information (version, platform, error messages) so we can help you.

-JD.

1874

z/OS Server / Preparing JES Spool to deliver files to CMOD via arsjesd?

« on: November 11, 2010, 06:09:59 PM »

Hi everyone. 

It's not often that I get to ask a z/OS question, so take it easy on me... 

I have a potential customer that is considering implementing CMOD -- but the question I couldn't answer for them was:
   "How do we configure JES to send files to CMOD?"

(As I understand it, files are sent from the JES Spool and delivered via TCP/IP to arsjesd, as if it was a printer.)

The follow-up question is: "How does arsjesd know what to name the file that's being received?"  The z/OS guy on the call seemed to think there was no dataset information for printouts in the JES queue.

Any assistance would be greatly appreciated.

-JD.

1875

MP Server / Re: TSM and expired documents

« on: November 06, 2010, 07:02:24 AM »

Hi Michael...

I'm not sure which format the archived database tables are in.  If they are in IXF format, you should be able to use DB2's 'import' command to bring the files back into the database -- but the corresponding information (arsseg records) might be missing as well, so you'll re-create them by hand.

It's an interesting problem -- please keep us posted!

-JD.