Messages

421

OD/WEK & JAVA API / Re: Searching mapped folder fields with multiple values

« on: November 20, 2019, 07:16:45 AM »

You'll want to be extra careful in allowing developers to submit SQL directly to the database.  Look up 'SQL Injection attack' to find out more. 

-JD.

422

General / Re: SFTP conversion

« on: November 09, 2019, 12:58:19 PM »

It's probably best to get the source system to produce the CMOD Generic Index File with the correct line endings for the destination system.

If not, there's a ton of ways to convert line endings when you're in a UNIX environment.

You didn't mention what the source system is, and I'm guessing you're using USS on z/OS.  If the source is Windows, you need to convert CRLF (carriage return+line feed) to NL (newline).

Your local (and likely bearded) UNIX guru should be able to help you do this in their preferred way.  I'm not sure which UNIX tools are available in USS.

-JD.

423

MP Server / Re: arssockd -T -I <<Instance Name>> will not stop CMOD

« on: November 09, 2019, 12:42:50 PM »

Hey Don.

It's okay to stop arssockd with the UNIX kill command.  It might be that you're not using the same ID that started arssockd.  Check on the process with the "ps -ef |grep arssockd" command, and double check that you're logged in as the same user that the process is running under.

-JD.

424

General / Re: SFTP conversion

« on: November 07, 2019, 01:15:31 PM »

It sounds like there's character conversion being done -- either FTP was fixing it, or SFTP is breaking it. 

I'm fairly certain that SFTP prefers binary mode, so either the file being produced wasn't compatible with your OS (and FTP was fixing it by transferring in ASCII) or it was, and transferring with SFTP is breaking it by changing the line ending characters.

You didn't mention which OS / CMOD version, but your server system administrator should know the best way to deal with this in your environment - it's been a remarkably common issue between different operating systems (UNIX / Linux / Mac / Windows / Mainframe) for decades.

-JD.

425

MP Server / Re: Issue with CMOD admin client, application and pdf index

« on: November 07, 2019, 11:43:05 AM »

If the plan is "rely on Adobe to fix it", we're all doomed. 

-JD.

426

MP Server / Re: Issue with CMOD admin client, application and pdf index

« on: November 07, 2019, 09:19:52 AM »

Is there a plan to fix the issues with the 64-bit version of the Admin Client?

427

MP Server / Re: CMOD 10.1.0.4 LDAP Synch

« on: October 24, 2019, 05:35:03 PM »

I suspect you'll need to create a new group that includes a query restriction under the Application Group Permissions tab, and remove their individual access rights to that App Group.  Otherwise, it does sound like a bug, and should probably be reported to IBM as a PMR.

-JD.

428

Windows Client / Re: WIndows Client / API supporting Drag and Drop Load

« on: October 24, 2019, 12:44:10 PM »

Hi Yousef. 

Having a user add a document to CMOD was supported, I think all the way back to IBM CMOD v8.  But like I said, it's not a very good idea.  The other problem is data quality.  What if a user puts in bad metadata?  The file will be lost forever, because people will search for 'good' metadata (customer number 12345) and it won't match because an end user might put a typo in that customer number (customer number 13245).

-JD.

429

Windows Client / Re: WIndows Client / API supporting Drag and Drop Load

« on: October 22, 2019, 07:40:19 AM »

Hi Yousef.

I know this type of functionality is desirable (and yes, even possible) but it's not really what CMOD is for.  When you store one document at a time, there's not a lot of benefit to just putting it in a filesystem.  In fact, you'll create a lot of overhead (database rows in the System Log, inodes in the cache, and metadata inside TSM) for very little benefit.

CMOD's big advantages are it's voracious appetite for documents that are all very much the same, with automatic indexing and amazing data compression.. not one-off uploads from end users.

You might want to consider dropping these files into Content Manager or Filenet, and once they've been through a specific workflow, archive them into CMOD for long-term safekeeping.

-JD.

430

iSeries / Re: Can we change TIFF documents to PDF

« on: October 15, 2019, 03:12:48 PM »

I think that the key word here is Image-only PDF.

Indeed it is.  CMOD can't read image files itself.  You need to do Optical Character Recognition on the image to produce the text that your indexing parameters would read.

If you want to try it out, Adobe Acrobat Professional includes an option to recognize the text on a page, and I've found it entirely acceptable for small to medium sized documents.  I'm not sure it would hold up under industrial volumes, but give it a try as a proof of concept.

-JD.

431

MP Server / Re: Need help with a query, DB2.

« on: October 14, 2019, 10:46:47 AM »

The CMOD Wiki to the rescue:  https://cmod.wiki/index.php?title=Useful_SQL_Queries_for_Content_Manager_OnDemand#How_many_documents_are_in_CMOD_Application_Groups.3F

And you want to do a "select distinct doc_name on <table>" to get a list of objects.  But this might not be a good way to reconcile your old vs. new loads.

-JD.

432

MP Server / Re: Determining metrics for specific application?

« on: October 08, 2019, 07:41:05 PM »

By AG, this is relatively straightforward.  By Application...  This is a nightmare. 

-JD.

433

z/OS Server / Re: Loads Failing

« on: October 08, 2019, 07:10:21 AM »

Post modified AGAIN to remove identifying information.

tbe2856:  Please anonymize the information you cut-and-paste into the forums BEFORE you post it!  We're trying to keep you from leaking information about your installation.

434

z/OS Server / Re: Loads Failing

« on: October 07, 2019, 08:25:11 PM »

Original post was edited (by me) to remove identifying information.

-JD.

435

Report Indexing / Re: Kofax Export of PDF Files Not Viewable in PDF Viewer

« on: October 06, 2019, 05:48:53 PM »

No problem.  We often just need a new pair of eyeballs to see what's happening in front of us.    I'd been fighting with a bug in some code for two hours, and figured it out while walking home for dinner. 

Take care. 

-JD.