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.

The BASE DN is different because we're using LDAP to authenticate the small set of users accessing documents with the Thick Client:
ARS_LDAP_BASE_DN="OU=XXXXX People,DC=XXX,DC=XXXX,DC=XXXXX,DC=com"

I'm attempting to run ARSLSYNC on my RHEL7 CMOD 10.5 development box. It's been giving me fits. No matter what I do the only way I'm getting any output is with these settings in ars.cfg
ARS_LDAP_SERVER_TYPE=AD
#ARS_LDAP_USER_FILTER=(&(objectClass=user)(memberOf=CN=CMOD_XXX_Business_dev,"OU=XXXX Groups,DC=xxx,DC=xxxx,DC=xxxxx,DC=com"))
ARS_LDAP_GROUP_USER_FILTER_USE_DN=FALSE
ARS_LDAP_USER_FILTER=(objectClass=user)
ARS_LDAP_GROUP_FILTER=(objectClass=group)
ARS_LDAP_GROUP_MAPPED_ATTRIBUTE=CN
ARS_LDAP_IGN_GROUPS=Security,CMOD_Admin,CMOD_Operations
The above gives me EVERYBODY in AD except CMOD_XXX_Business_dev. I can't get the filters to work to bring in the only group with 4 users into my Dev environment. According to my identity people the group exists in AD and has 4 users defined.
If I attempt to use the USER_FILTER code ARSLSYNC doesn't find the users or group running with the just -t -v options.
Has anyone been successful using ARSLSYNC to provision users in CMOD that are part of Group?
I am in consultation with IBM Lab Services as part of a work effort to authenticate a small group of users accessing documents via the Thick Client via AD and SSL, which is working fine. Lab Services is also looking at the issue as I've sent them the trace and output.
I'm running CMOD MP 10.5.0.5 on a RHEL7 server with DB2 11
I know next to nothing about AD or LDAP.

I had to export our users in production yesterday for our annual SOC Audit (Sarbanes Oxley) and the export ended up with 24 MORE ID's than what was displayed in the Admin GUI.
I went through ID by ID to figure out which ID's were missing from the GUI.
Has anybody ever experienced this?
I have a ticket open with IBM.
CMOD Ver 10.5.0.5
OS RHEL7
Library/Object server are the same server.
I am the admin and exported the User objects under my ID.

I had a ticket open with IBM and they've pretty much said it's TSM causing the lag. I'd like to bypass looking in CACHE first only because I know for a fact that all the documents are in TSM only. I'm waiting on my TSM guy to be available so I can get him to open another ticket for TSM to see if it can be tuned to work faster. The external entity may need the pdf's individually because they definitely don't use CMOD so I don't see the value of generating a generic index file. But what do I know.

I've got to extract a little over 170K pdf documents (or more) from my CMOD instance to give to the external entity that bought one of our subsidiaries. I had intended to use ARSDOC GET with the LOAD ID (-X ) and -c -g -N parameters to get the documents but my tests last week on a large load (4182 pdf documents) took almost 4 hours to run. I don't know if I'll have to do -c but I haven't yet heard from the external entity on how they need the pdf documents (they don't use CM or CMOD). TSM seems to be the sticking point since all of the documents have migrated out of cache and are now in TSM. IBM indicates that TSM is the problem. I'm open to suggestions of ways to speed this up without affecting my internal and external users. I'm on CMOD 10.5.0.5 with DB2 and TSM on a RHEL7 server. TIA