Messages

466

MP Server / Re: Report Failed - AN ACIF STORAGE REQUEST WAS UNSUCCESSFUL - REQUEST SIZE 314 GETM

« on: August 06, 2019, 04:57:21 AM »

: APK415I FORMFEED=YES

: APK493S A VALUE OF YES FOR THE FORMFEED PARAMETER IS NOT ALLOWED WITH THE CONVERT=YES, CC=YES, OR TRC=YES PARAMETERS.

One of the four parameters in the error message needs to change, I'm going with the first one that it's complaining about. 

Let us know if it works!

-JD.

467

iSeries / Re: Can /QNTC file System be used in Generic Indexer IND file GROUP_FILENAME parm?

« on: August 01, 2019, 11:58:10 AM »

On the MP systems, you can do this if the filesystem is mounted locally and available to users on the system.  Otherwise, I advise customers to put the data in it's own directory, and remove any directories from the file name specified on the GROUP_FILENAME parameter in the generic index file.  Then I just transfer the whole directory to the machine where it will be loaded with scp/sftp or as a zip/tar file.

-JD.

468

Report Indexing / Re: Bad Character???

« on: July 30, 2019, 07:50:09 AM »

This issue was also mentioned in one of the previous ODNews newsletters:  http://www.ibm.com/support/docview.wss?uid=swg27041378

-JD.

469

MP Server / Re: ARSLOAD Getting ARS4305E Error

« on: July 25, 2019, 06:25:13 AM »

Yup, remove the .ind from the file name on the arsload command line. 

The wiki has been updated to reflect this as well.

-JD.

470

z/OS Server / Re: Convert AFP to XML

« on: July 18, 2019, 04:56:27 AM »

Yeah, this is more in the realm of other business partners.  I'll see if I can get one of the Datawatch or Crawford Tech folks to chime in here.

-JD.

471

MP Server / Re: How to force disable local authentication when connect to LDAP

« on: July 15, 2019, 12:27:30 PM »

Ah!  I'm happy to be corrected and learn about a previously unknown feature...   

-JD.

472

MP Server / Re: How to force disable local authentication when connect to LDAP

« on: July 15, 2019, 06:15:20 AM »

I think the reason this doesn't exist is because if the AD/LDAP server is down, then NOBODY can log in to CMOD -- not even administrators.  And that could cause all kinds of crazy failures - like failed loads, etc.

-JD.

473

MP Server / Re: Why not FileNet for PDF Statements with IBM

« on: July 12, 2019, 05:15:08 AM »

It also depends on volume.  Most of the customers that have wanted to move to CMv8 or Filenet for bill presentment have turned back after realizing that only CMOD can load millions of documents a day.  One proposed migration from CMOD to Filenet I was working on in 2012 showed we could extract their collection of over 1 billion documents in about 30 days...  but Filenet would take nearly 2 years to load them.  Maybe they had some configuration/performance issues in Filenet, but the migration got cancelled immediately afterwards. 

And you *can* get amazing compression with CMOD if your document production system produces PPDs, allowing CMOD to remove the resources and compress the remaining data.  I've heard customers can get 300:1 compression with statement-type PDFs.

-JD.

474

MP Server / Re: Database Migration

« on: July 10, 2019, 01:20:36 PM »

Last time I heard of this being done, the migration from Oracle to DB2 is problematic because of the different data types.  I'm interested to see if Alessandro has something to say about this - I vaguely remember him mentioning it previously.

-JD.

475

Content Navigator / Re: REST Service for ICN

« on: July 08, 2019, 06:13:39 AM »

Yeah, it doesn't sound like you're using the ODWEK APIs, and are probably doing federated searches with some other tool.

Use the IBM CMOD ODWEK Java APIs: https://CMOD.wiki/dox/ODapiDoc/

Give us a little more information about your environment (OS/ software / versions) so we can help you better.

-JD.

476

MP Server / Re: Order of updating DB2, CMOD and Linux

« on: July 03, 2019, 08:59:18 AM »

For IBM CMOD Upgrades, if you're going to take an outage, you do everything that needs to be done at once.  If you have different teams, you have the OS upgraded first, then the DBAs and CMOD Admins can work in parallel after the system comes back up.

-JD.

477

z/OS Server / Re: Getting content out of CMOD z/OS

« on: June 27, 2019, 05:01:59 PM »

I’ll send you a DM with more info.

-JD.

478

MP Server / Re: Ondemand - data restoration after removing app gr

« on: June 27, 2019, 04:54:13 PM »

Consider adding it as an Enhancement Request. 

479

z/OS Server / Re: Getting content out of CMOD z/OS

« on: June 26, 2019, 10:22:04 AM »

Yes, just confirming that this plan is ridiculous.  I have almost 25 years experience with CMOD, and have a deep understanding of how CMOD objects and compression works -- and I would never do this.

I have an extraction utility that will do this job if your client is interested.

-JD.

480

MP Server / Re: Ondemand - data restoration after removing app gr

« on: June 26, 2019, 10:18:43 AM »

I'd have to say I agree with Stephen.  There's only so much the developers can do to protect you from yourself.  Requiring an admin login & password as confirmation of deletion was added after it was deemed 'too easy' to delete AGs.

Otherwise, this becomes a lesson in not granting admin access to people who don't have the appropriate skillset, or putting extra policy requirements in place when doing deletions (two admins present, and one overseeing the other).

-JD.