Messages

1936

MP Server / Re: Report Wizard error

« on: May 16, 2010, 12:57:48 AM »

If you're using fully composed AFP, you can ask the people who generated the data if there are TLE (Tagged Logical Elements) in the file.  If there are, it'll be very easy to do the indexing with ACIF.  Otherwise, you'll probably want to contact your IBM Rep about using the Visual Indexer.

If you're having problems with line data, make sure your code page setting is correct.

-JD.

1937

MP Server / Re: Report Wizard error

« on: May 13, 2010, 06:33:55 AM »

It might sound silly -- but what are you trying to open? 

The parameters that you define elsewhere in the Application (data type, line length or line-end characters, code page, etc.) all affect how the ASCII or EBCDIC data is displayed.

-JD.

1938

z/OS Server / Re: arsdoc get of .out, .ind, .ann, .ang with preview exit

« on: May 10, 2010, 09:31:57 AM »

Hi Sue.

First thing -- your second command has -x (with loadID) AND an SQL Statement.  In the MP world, you only need one of these.

Second, I believe I've seen this behavior before in a server consolidation back in 2006...  When you load the extracted file, as long as the generic index entries are next to each other (ie, the generic index is sorted by object id, then byte offset), arsload should be smart enough to NOT store the duplicates.  Give it a try and see if this works in your environment.

-JD.

1939

MP Server / Re: Creating User Exit

« on: May 04, 2010, 06:34:32 AM »

Hey Alan...

The built-in arslog exit has the basics of what you need, including examples.

I have a few suggestions when it comes to User Exits (and specifically the arslog exit)...

• Do the absolute minimum amount of work possible inside the exits -- a shell script to evaluate the message number, and print some variables to a file is all it should really need.  Launching an interpretive language like Perl (and compiling your source code) several times a second will bring your system to a crawl.
• Archive the logs on a regular basis (daily, weekly, monthly).  This can be easily achieved by including the year and month in the file name you create.
• Process the log with a higher-level language later.  Do your heavy lifting and slicing-and-dicing later.  If you need real-time monitoring, consider letting your enterprise monitoring software grab the log file and process it itself.
• Be particularly cognizant of the time it takes to run your script.  While you're developing it, use tools like 'time' to measure how long it takes to execute, and wring out each and every hundredth of a second of performance -- this will keep your server from getting bogged down.  Use a script to read individual lines from a file and launch the script (say, a thousand times) because this is precisely how CMOD will use it.

Good luck!

1940

MP Server / Re: 8.3 to 8.4 migration

« on: April 06, 2010, 06:25:41 AM »

Just finished a similar upgrade in March.

In 7.1.2.9 (aka 8.3) there was a change to ACIF that means some of your loads (specifically AFP docs with coverpages) will fail.  Add 'IndexStartBy=2' to your indexer parameters.  If you're migrating from an earlier version (7.1.2.0 - 7.1.2. you'll want to keep an eye out for this one.

Also, my customer was bitten by a bug (being unable to query the system log before the date of the upgrade) that was supposed to have been fixed in 8.4.1.4.  When we implemented the fix, the problem remained.  They're currently working with IBM for a solution.

-JD.

1941

MP Server / Re: System load application group fields

« on: March 23, 2010, 06:03:38 AM »

Hey Sandeep...

I just re-read my post -- it should read, "your loads are sufficiently large for the overhead from the Load Log *NOT* to be a problem".

Sorry! 

-JD.

1942

MP Server / Re: System load application group fields

« on: March 18, 2010, 04:21:12 AM »

Hi Sandeep...

The impact will be minimal.  It's no worse than adding load messages to the System Log -- a single record with multiple fields.

If I remember correctly from the last time I was down there, your loads are sufficiently large for the overhead from Load Log to be a problem.

-JD.

1943

General / Re: Is anyone loading W2's in CMOD?

« on: March 12, 2010, 02:55:30 PM »

W2s -- in what format?  AFP, or line data with AFP overlays?

1944

MP Server / Re: Successful load message contents explanation required

« on: March 11, 2010, 08:04:59 AM »

I'm not exactly sure why there's a disparity between the input size in the System Log and the ACIF output.  This might need someone with visibility to the CMOD source code in order to explain it.

To answer your question about database growth...  There are some guidelines in the IBM Planning Guide for CMOD about how to calculate the size of databases, but essentially, because database rows for a particular Application Group are all the same size, growth is linear.  Calculating bytes used is a headache, but counting the number of rows is easy, and an accurate relative representation of growth.

-JD.

1945

MP Server / Re: Error while installing CMOD 8.4.1.0

« on: March 09, 2010, 07:59:58 AM »

There are two types of installation packages -- upgrades, and base levels.

The ones you pull from the IBM FTP site are all upgrades -- which require the installation of a base-level first.

If you get the 8.4.1.0 Installer from a media kit, it'll be a base level installer -- and it won't have any requisites.

If you get the 8.4.1.0 Installer from the IBM FTP site, you'll need to have a base level installer for 8.4.0.0.

It's hard to imagine that someone would pirate CMOD, but this is one way that IBM protects against it.

-JD.

1946

Other / Re: CMOD 7.1.2.14 stable? eclient compatiblilty?

« on: March 03, 2010, 07:35:22 AM »

Hey Shannan...

The only real test of compatibility is promoting this version through successive test 'regions' - Dev -> QA -> UAT -> Production.

If you want to know which bugs were fixed in a particular patch level, check out the 'ReadMe' docs for newer versions to see what was patched.  You can find the readme's for each particular version on the IBM FTP site:

For example, this is the readme for 8.4.0.0, the next version of CMOD that was released:
  ftp://ftp.software.ibm.com/software/ondemand/fixes/v840/8.4.0.0/readme.txt

If you scan through the doc, it lists the changes made and APARs patched from the prior version(s).

As a General FYI, the client access API for CMOD doesn't change much from version to version -- it's the Admin API that can change drastically when new features or functionality is added to new versions.

Good luck!

1947

Announcements & News / ODUG @ IOD EMEA 2010

« on: March 01, 2010, 09:12:04 AM »

Hello ODUG Members & CMOD Users!

I'm pleased to announce that in co-operation with IBM, ODUG will have a presence at the IBM Information OnDemand EMEA Conference in Rome, Italy, from May 16th to 19th, 2010:
http://www.ibm.com/software/uk/data/conf/

*SEVEN* CMOD-specific sessions have been selected out of the thousand or so that were submitted.  In addition, there will be a "Community Cafe" in the expo for User Group members to meet, and discuss topics that are important to you and your organization.

The CMOD-related sessions are:
2785 : Hottest newest Storage Appliance: IBM Information Archive
3420 : What is New for IBM ECM Customers
3443 : IBM Content Manager OnDemand Update
3717 : Best Practices for Content Manager OnDemand Administrators
3749 : Migrating Data to or from Content Manager OnDemand
3684 : Archive large scale XML data: The SEPA case
3255 : Getting Added Value From Your Digital Archive  -=> LATE ADDITION! <=-

Want to see what else IOD EMEA has to offer?
Search for Sessions by keyword or track:
   https://www-950.ibm.com/events/global/iodemea/sessions/

Already registered?  The Session Selection tool is online!
The IOD online Agenda tool is online!  Go online and select your courses now:
   http://www.IODagenda.com/

Marketing Blitz!
Please help get the word out about IOD EMEA 2010 by distributing the link to this post to anyone you know with interest in CMOD -- Management, Executives, IBM Sales Reps, Support, or Client Reps:
   http://www.odusergroup.org/forums/index.php?topic=379

Discount Code for ODUG Members now available!  Save 10% on IOD EMEA Registration!
If you're already a member, send me a message, and I'll forward you the code.
Not a member yet?  Sign up for the ODUG Forums, and I'll send you the discount code within 24 hours!

I look forward to seeing you in Rome!

-JD.

1948

MP Server / Are you on MultiPlatforms and using the OnDemand Web Administration interface?

« on: February 23, 2010, 12:44:44 PM »

Please feel free to explain your answer below!

1949

z/OS Server / Are you on z/OS and using the OnDemand Web Administration interface?

« on: February 23, 2010, 12:43:15 PM »

Please feel free to explain your answer below!

1950

MP Server / Re: CMOD (Windows) - DR scenarios?

« on: February 23, 2010, 07:14:46 AM »

Hi Shannan.

With CMOD, there's no simple way to provide DR, as there is in CM.

Most customers I work with choose to go with two production servers in geographically diverse areas, and keep them synced by loading the same data into both sites.

It seems that most server hardware is robust enough to not fail, even after years of service -- for example, I'm scheduled to do an upgrade from an RS/6000 H80 this year -- that's hardware that's 10 years old, and is still dutifully serving users!

What seems to cause the most incidents and downtime now is the human element.  In your CM system with a HADR configuration, if a DBA accidentally drops a table, or a user deletes some documents, that change would be replicated to the remote system -- completely eliminating the benefit of using HADR.

With the dual-hot scenario, you can have two servers up and running, ready to serve your users individually, or in a load-balanced scenario.

You would normally switch between the servers with DNS (if you're using the thick client) or build some sort of 'switch' into your web app if you're using ODWEK or the Java API to serve users.

Hope this helps!

-JD.