I'm putting my functional requirements document together and step one will be send the pdf's first with the caveat that if they don't we'll have more administrative overhead. There's a custom process that uses the CMOD user exit for additional processing.
The vendor is going to be responsible for quality control.
As far as the daemon starting the load, it won't unless you know something other than what is stated in the IBM documentation. The files the daemon will automatically load are .ARD and .PDF. From the manual (online) "The ARSLOAD program will process any input file that has a file type of ARD or PDF."
That's why the new location will be out of the ARSLOAD daemon "view" and under the control of a script.

I currently have my arsload libraries defined for the CMOD arsload daemon as /app/arsacif/acif1 /app/arsacif/acif2 and /app/arsacif/acif3.
I want to define another file system /app/arsacif/acif4 that will be strictly for input coming to be indexed with the Generic Indexer with the load triggered by a scheduled script. The expected payload could be (more or less) 20k of PDF files (the source doesn't want to put them in one large file anymore because it becomes too large for them manipulate).
Is that a good or bad idea?
I'm trying to brainstorm ideas to keep this payload in CMOD. I've already told the client that we won't accept individual pdf files to load one at a time. Been there, done that and loading took too long.

The end result determined that when the number of documents in a batch was increased (up to 12000) the RESTYPE=ALL created very large resource files. Per IBM when resource files approach 500MB, there's increased search overhead to search a large resource file by arspdump to rebuild the documents when retrieved. We changed RESTYPE=NONE and haven't seen this issue since but that increases our storage footprint for the documents.

It's decent reference source when one can't get direct answers from IBM or when IBM says sorry that's a Lab Services issue/problem/function. Like last week when I needed to interrogate a CMOD appgroup for documents greater than 5MB for a project. I eventually figured out how to do it.

I thought I was losing my mind last week when I went to reference odug for something CMOD and couldn't get it.  I'm glad you're back.

We're still having issues with opening PDF's.
The documents use Page Piece Dictionary Indexing.

INDEXSTARTBY=1
RESTYPE=ALL
INDEXMODE=INTERNAL
Data Compression is OD77

Compressed Object Size is 100k
AppGroup has 17 DB2 fields with 4 Index type and the remaining are filter. 6 of the filter fields are 250 bytes long to allow for a comma delimited array of claim numbers to be populated.
Documents are indexed monthly and stored in CACHE for 60 days. We run maintenance once a week.

The indexed pdf documents can be anywhere from 14 to 200 logical pages. A normal load totals between 400k and 500k documents with over 100k where the consumers are 'paperless'.
We run a notification process to notify our consumers that their documents are ready to view.
The consumers access the documents via ICI & ODWEK (I have no details as that is owned by our CM8 team).
After the notifications go out the web portal is inundated with document get requests, more than 100 and less than 150 in minutes.
The PDF's are uncompressed using our temporary file system but the sheer volume of the requests overwhelms CMOD. I had at one point on Wednesday over 20GB of 200 RECONVERT, CONVERT and TMP.err files being retrieved from CACHE.

CMOD is being blamed for the latency on the ODWEK front end. I say it's them or a robot process causing the high traffic. I'm going to request that our temp file space be moved to a mount point after the first of the year (year end/holiday changes are basically frozen until January) to see if that helps.

I found out last week from IBM support that a bug has been introduced in the V10.5.0.8 fixpack where the 30 minutes arssockd check is not writing the 201  to the CMOD system log. From my ticket:

"A few months ago we realized that CMOD 10.5.0.8 does not generate the 201 message (as it should). This was an oversight on our part.
Its been corrected in the next fixpack (10.5.0.9) yet to be released."

I found the issue after migrating my sandbox server from RHEL7 V10.5.0.6 to RHEL8 V10.5.0.8.

I'm going to be getting the 10.5.0.7 fixpack for my next server migrations if IBM doesn't have the fix ready for production when I need it.

Figured to let the community know.

I'm migrating CMOD from RHEL7 to RHEL8 servers. It never goes smoothly.
My current issue is the LDAP authentication. All the parameters that are currently working on the RHEL7 server aren't working on RHEL8.
Besides the OS difference when I installed CMOD on RHEL8 I also patched to 10.5.0.8 whereas the version on the RHEL7 is 10.5.0.5.
While IBM is working on my ticket the thought occurred to:

1. Rollback the RHEL8 version to 10.5.0.5 OR
2. Upgrade the RHEL7 to 10.5.0.8

I was just wondering if a rollback was possible or just uninstall and reinstall CMOD to the known working version we have.

 

This is CMOD 10.5.0.5 running on a RHEL7 server with the temporary files going to a filesystem (not /tmp) in the root directory (forgive me if I use the wrong terms because I'm a mainframer with enough server knowledge to be dangerous).
The documents in question use Page Piece Dictionary attached is the output of the App Group.
The documents load once a month and we can load between 400k and 500k depending. I scanned the system log for the previous month and there was no overwhelming issue logged as errors or excessive activities for arssockd.
It might have been another team that changed their code that interrogates CM8 and CMOD. I have no visibility into what they do.
There are 4 applications in this group using the same indexing.
It's been MANY years since this has happened to where it stopped arssockd.

I'm running CMOD 10.5.0.6 on a RHEL7 server with multiple instances of ODWEK interrogating the server for PDF documents stored using Page Piece Dictionary.
Last night we started experiencing an abnormally large volume of DocGets for those PDF's. The system log showed multiple error types, below

09/20/2024 09:41:29   ODUSER1     383561602   Error   No      116   Unable to stat file >/app/arstmp/ARS.28565.00007FCEB51E8700.CONVERT.TMP<.  The error number is 2  Srvr->full name removed to protect the innocent non-SSL<-
09/20/2024 09:41:25   ODUSER1     383559016   Error   No      116   Unable to stat file >/app/arstmp/ARS.28565.00007FCEB19CC700.CONVERT.TMP<.  The error number is 2  Srvr->full name removed to protect the innocent non-SSL<-
09/20/2024 09:41:25   ODUSER1     383560897   Error   No      116   Unable to stat file >/app/arstmp/ARS.28565.00007FCEB59EC700.CONVERT.TMP<.  The error number is 2  Srvr->full name removed to protect the innocent non-SSL<-
09/20/2024 09:41:24   ODUSER1     383562667   Error   No      119   Unable to write to file >/app/arstmp/ARS.28565.00007FCEA958A700.CONVERT<.  The error number is 28  Srvr->full name removed to protect the innocent non-SSL<-
09/20/2024 09:41:24   ODUSER1     383563774   Error   No      114   Unable to open file >/app/arstmp/ARS.28565.00007FCE57AF1700.CONVERT<.  The error number is 28  Srvr->full name removed to protect the innocent non-SSL<-
09/20/2024 09:41:24   ODUSER1     383563509   Error   No      114   Unable to open file >/app/arstmp/ARS.28565.00007FCE576EF700.CONVERT<.  The error number is 28  Srvr->full name removed to protect the innocent non-SSL<-
09/20/2024 09:41:24   ODUSER1     383559662   Error   No      116   Unable to stat file >/app/arstmp/ARS.28565.00007FCED59EC700.CONVERT.TMP<.  The error number is 2  Srvr-> full name removed to protect the innocent non-SSL<-
09/20/2024 09:41:24   ODUSER1     383563570   Error   No      119   Unable to write to file >/app/arstmp/ARS.28565.00007FCEA3359700.RESCONVERT<.  The error number is 28  Srvr-> full name removed to protect the innocent non-SSL<-
09/20/2024 09:41:24   ODUSER1     383563291   Error   No      114   Unable to open file >/app/arstmp/ARS.28565.00007FCE578F0700.CONVERT<.  The error number is 28  Srvr->full name removed to protect the innocent non-SSL<-
09/20/2024 09:41:24   ODUSER1     383563323   Error   No      114   Unable to open file >/app/arstmp/ARS.28565.00007FCE57CF2700.CONVERT<.  The error number is 28  Srvr->full name removed to protect the innocent non-SSL<-
09/20/2024 09:41:24   ODUSER1     383560450   Error   No      116   Unable to stat file >/app/arstmp/ARS.28565.00007FCEB45E2700.CONVERT.TMP<.  The error number is 2  Srvr->full name removed to protect the innocent non-SSL<-
09/20/2024 09:41:24   ODUSER1     383560203   Error   No      116   Unable to stat file >/app/arstmp/ARS.28565.00007FCEDE7CB700.CONVERT.TMP<.  The error number is 2  Srvr->non-SSL<-
09/20/2024 09:41:24   ODUSER1     383560411   Error   No      116   Unable to stat file >/app/arstmp/ARS.28565.00007FCEB4FE7700.CONVERT.TMP<.  The error number is 2  Srvr->full name removed to protect the innocent non-SSL<-
09/20/2024 09:41:23   ODUSER1     383563374   Error   No      114   Unable to open file >/app/arstmp/ARS.28565.00007FCE921F0700.CONVERT<.  The error number is 28  Srvr->full name removed to protect the innocent non-SSL<-
09/20/2024 09:40:28   ODUSER1     383563231   Error   No      119   Unable to write to file >/app/arstmp/ARS.28565.00007FCEAF9BC700.RESCONVERT<.  The error number is 28  Srvr->full name removed to protect the innocent non-SSL<-
09/20/2024 09:40:25   ODUSER1     383561583   Error   No      116   Unable to stat file >/app/arstmp/ARS.28565.00007FCEA6974700.CONVERT.TMP<.  The error number is 2  Srvr->full name removed to protect the innocent non-SSL<-
09/20/2024 09:40:24   ODUSER1     383563267   Error   No      114   Unable to open file >/app/arstmp/ARS.28565.00007FCEAD1A8700.CONVERT<.  The error number is 28  Srvr->full name removed to protect the innocent non-SSL<-
09/20/2024 09:40:24   ODUSER1     383561931   Error   No      114   Unable to open file >/app/arstmp/ARS.28565.00007FCEA6371700.CONVERT<.  The error number is 28  Srvr->full name removed to protect the innocent non-SSL<-
09/20/2024 09:35:26   ODUSER1     383546145   Error   No       20   SM Error: Unexpected end of data encountered6, Return Code=6, Reason=arscssm.c, File=584, Line=  Srvr->full name removed to protect the innocent non-SSL<-
09/20/2024 09:35:15   ODUSER1     383546145   Error   Yes      257   PDF document/resource conversion error.  See stored document for more information.

So many that the file system where we write the files to filled up and arssockd and arsload (running as a daemon) stopped. I restarted it and the rest of the night everything was fine. Then it happened again this morning and we had to restart CMOD 3 times because I couldn't keep up with deleting the files out of the filesystem.
Interrogation of arssockd also showed abnormally high volume of activity, upwards of 150+ current activities displayed with ps -ef | grep arssockd

One of the 257 errors showed ARS4923E PJoin error code 1073938445 The file may be read-only, or another user may have it open. Please save the document with a different name or in a different folder.

Had anybody run into this? Do you have a way of identying the document or documents that could be involved? How can we prevent users from trying to retrieve documents that they might have already tried to retrieve (if the above error isn't a red herring)?

Did you ever get your answer?

The certificate I was given by the group responsible for AD expires next year and is working in the lower environments. I just did a full server reboot last night (my maintenance window) and that didn't help. I changed the port to 389 and set SSL to FALSE, I have repopulated the keyring db 3 times, updated my LDAP ID 3 times. My server admin (I know enough about Linux to be dangerous) and there's no outbound port blocked for 389, 636, or 3269 on the CMOD server. IBM had me add ARS_LDAP_REFFERALS=FALSE and I tested that last night with no success.

My last options will be use the other ID to connect and/or fine tune the BASE_DN to OU=XXXXX People,DC=xxx,DC=xxxx,DC=xxxxx,DC=com.

This is what I get:
9978:140246905972480 06/16/2024 21:08:28:097711 FLOW arsldap.c(2427)ArcLDAP_Authenticate:Enter
29978:140246905972480 06/16/2024 21:08:28:097767 FLOW arsldap.c(2350)ArcLDAPP_CheckIgnoreUsers:Enter
29978:140246905972480 06/16/2024 21:08:28:097776 FLOW arsldap.c(2398)ArcLDAPP_CheckIgnoreUsers:Return rc=0
29978:140246905972480 06/16/2024 21:08:28:097786 ERROR arsldap.c(2446)ArcLDAP_Authenticate:LDAP has not been initialized
29978:140246905972480 06/16/2024 21:08:28:097797 FLOW arsldap.c(2772)ArcLDAP_Authenticate:Return arccs return code=6,ARCCS_FAILED

I'm fresh out of ideas.

I've got a possible weird situation. I'm running CMOD MP 10.5.0.5 on 3 RHEL7 servers. With Lab Services help I've managed to implement LDAP Authentication using SSL on the 2 non-prod servers. When I attempted to implement in Production, I've run into a problem where the LDAP ID won't perform the initial BIND. I was able to use the same ID production ID to BIND on one of the lower environment servers.
1. I've checked and rechecked my typing for the LDAP parms in ars.cfg along with having them peer reviewed. I've redone the LDAP BIND ID and password in the stash file.
2. The .pem certificate is the same across all 3 servers just has different labels in the keyring DB.
3. Initially I used 1 ID to BIND on the 2 non-prod servers and a second ID to BIND in PROD.
4. The Linux team assures me that the traffic outbound to the AD server is not blocked on either port 636 or 3269.

I've got a ticket open with IBM but I was wondering if anyone in the user group had any issues.
I'm out of ideas.
Now I also see that there is also an issue in our company with CM failing LDAP Authentication with SSL enabled.

This is for implementations that use the Thick Client for users to retrieve documents.
I have finally gotten ARSLSYNC working in my sandbox enviroment. YAY Me!
I'm not really thrilled with what I'm seeing.
We are using sAMAccountName for the BIND and MAPPED attributes for LDAP which track back to how we identify employees and contractors in my company.
For the SYNC we're setting USER_FILTER to objectClass=user memberOf... and for GROUP_FILTER = objectClass=group cn=CMOD*dev (yes I'm skipping typing in the full text, just go with me.)
When I run the SYNC I only get the value for the User ID but not the Name or Descriptions that we use when manually loading a user to CMOD. IBM Lab Services says that's all we get and I'm not thrilled. I like to see names and departments that go with the user ID.
Does anyone else care? Has anyone else be able to solve this? Lab Services suggested I request an enhancement to ARSLSYNC.
Because of this we're delaying our ARSLSYNC provisioning until next year.

He did and I now have an even larger list of users and groups than I had yesterday after I pulled all the filtering off the LDAP_USER_FILTER.
Enclosing the (memberOf...) statement in "" didn't help.