Show Posts

This section allows you to view all posts made by this member. Note that you can only see posts made in areas you currently have access to.

Messages - Justin Derrick

Pages: [1] 2 3 4 5 6 ... 133
Content Navigator / Re: Opening PDFs using thick Client 32-bit Error
« on: June 09, 2024, 04:15:41 PM »
Sounds like the new version didn't include the requisite APIs/DLLs/Plugins.

MP Server / Re: Unique ID format
« on: June 05, 2024, 03:31:50 PM »
Please correct me without hesitation!  I didn't know that UUIDs followed specific standards, and I'm happy to learn about it.  :)


MP Server / Re: Unique ID format
« on: May 31, 2024, 08:46:55 AM »
Hi Nils.

It's not documented, but I believe it's a 64-bit random number represented as hexadecimal that just has dashes inserted in arbitrary places.

This is different than Hash values, which are SHA-256 hashes based on the contents of the documents.

Since the change you're suggesting will make alterations to DB2 database tables, you absolutely MUST test your solution thoroughly in non-prod regions.  :)

A more supported way to do it would be to extract and load the old data into a new App Group that has the UUID configuration.


MP Server / Re: ARSLSYNC Question
« on: May 02, 2024, 09:05:04 AM »
What's the advantage to mirroring this data locally?  The System Log only records the User IDs anyway.  If you want to look up who a user is, copy & paste the User ID into your LDAP Client / Org Chart / Teams / eMail client, and you should get the information you're looking for.

I agree about the Enhancement Request, but spend the time to think through how it would be implemented and what features you (and other CMOD customers) might want.


Just a quick update since CMOD v10.5 FP8 was released this week.  The new FixPack doesn't change the behaviour of CMOD, because altering the current behaviour would mean that OnDemand would no longer be FIPS compliant.

The documentation has been updated to describe the change, but I imagine it would be trivial to miss this very important change:


IBM Global Security Kit is a library that is used by many IBM products to provide cryptographic functions - encrypting data, hashing passwords, etc.  It is generally a good security practise to keep your GSKit at the latest release version, to ensure the highest level of protection for your data and communications.

In one of the most recent FixPacks of GSKit (, IBM added 'post quantum cryptography' support to key databases.  "Post-Quantum Cryptography" ('PQC') refers to cryptographic methods that are resistant to factoring attacks against standard cryptographic methods that are quickly becoming feasible due to advances in quantum computing.  This change breaks CMOD v10.5.0.7 (and likely all lower versions).

With the latest GSKit Fixpack, there was no notification, no included README file, and no updated documentation released to describe the change.  It is considered bad software development practise to introduce a change that breaks upstream products, and enable that change by default in minor or 'fix' releases.

CMOD bears some of the responsibility for this issue, as it currently ignores the unreadable key database, didn't produce any error messages (or pass through the GSKit errors), and arssockd starts up, exposing an unresponsive SSL/TLS port on the server's network interface.  Only through extensive server tracing can a cryptic and uninformative GSKit error message be found.

This issue affects both server and client software.  Key Databases must be re-created for both using an undocumented option in order to work with the latest Content Manager OnDemand FixPacks.

Other products may experience similar issues if key databases are created with the latest versions of GSKit.

More information and a solution can be found here:


You didn't mention if you're using a Certificate Authority (CA) or a self-signed certificate, so the answer will be a little vague...

Check DB2's key database for the Spectrum Protect server certificate -- if the SP server cert is self-signed, you'll have to add a copy to the DB2 database's key db.  If the SP server cert was signed by your organization's CA, then you need to make sure you have the full certificate chain (root + intermediate certificates) inside that key database.



It's best to use local storage for CMOD functions - database, transaction logs, cache filesystem, and temporary space for indexing and loading -- having these filesystems remote means that a network issue can bring your server down in ways that are hard to recover from.  I'd only use NFS for long term "secondary" storage.


That's a big question.  :)

First, let me start with an unpopular truth:  Object servers are an obsolete idea. 

The architecture of CMOD was designed in the early 90's, when storage and bandwidth were exceedingly scarce and expensive - there were also very hard physical limits on how much storage you could connect to a single server.  The first CMOD server I was responsible for had 4 112Mhz CPUs, 512MB of RAM, 24GB of hard drives, and a 100GB tape library -- and it was one of the most powerful midrange systems in the company -- .

What should you do instead? 

Run a single CMOD server, and use any of the cloud-ish storage tech or Cheap and Deep filesystem storage.  Storage, CPU, Bandwidth...  All are relatively cheap.  The only remote loading you should be doing is PDFs on a Windows server.


z/OS Server / Re: XML Indexer VS Generic Indexer for PDFs
« on: March 04, 2024, 09:21:03 AM »

z/OS Server / Re: XML Indexer VS Generic Indexer for PDFs
« on: March 04, 2024, 09:19:02 AM »
I think there's some confusion -- you can add CMOD document metadata to XML files, and you can add PPDs to PDFs for CMOD metadata, but I don't think you can provide metadata in XML format to replace the Generic Index format.

See the presentation on XML:,2421.0.html

MP Server / Re: Loading reports online from the AS/400 to CMOD MP
« on: February 29, 2024, 11:01:27 AM »
Man, if we all showed up in one place to exchange the drinks we all owed one another...  There would be have to be a line of ambulances waiting for us that stretched around the block.



MP Server / Re: PDF from ARSDOC GET can see only one file
« on: February 29, 2024, 10:59:25 AM »
Page 255 of the document I linked.


MP Server / Re: PDF from ARSDOC GET can see only one file
« on: February 29, 2024, 06:26:09 AM »
It's not a strange format -- it's the CMOD Generic Index format (v2) which has been around for nearly 20 years, and is well documented:

If you're not loading the data to another CMOD server, you need to write a utility to do the splitting and convert the metadata, or work with someone who has already done that work.  ;)


Pages: [1] 2 3 4 5 6 ... 133