Messages

1

MP Server / Re: ARSLSYNC Issues

« on: April 24, 2024, 07:27:12 AM »

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.

2

MP Server / Re: ARSLSYNC Issues

« on: April 23, 2024, 11:41:31 AM »

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"

3

MP Server / ARSLSYNC Issues

« on: April 23, 2024, 09:10:38 AM »

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.

4

MP Server / User Object Count Discrepancy Between Admin GUI and ARSXML Export

« on: March 26, 2024, 06:45:57 AM »

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.

5

MP Server / Re: How Can I Optimize ARSDOC GET

« on: January 23, 2024, 11:37:17 AM »

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.

6

MP Server / How Can I Optimize ARSDOC GET

« on: January 23, 2024, 09:11:46 AM »

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

7

MP Server / Re: I need a sample file + overlay

« on: January 23, 2024, 09:00:49 AM »

I had to do this years ago to apply our logo and standard disclaimer to a line data file. I had to define a FDEF, PSEG and OVLY in the CMOD indexing parameters. Unfortunately I have no sample data any longer just the resources. The line data was sent via MVSDOWNLOAD from the mainframe to my RHEL UNIX servers. I'm not an AFP programmer, someone does that and I get to copy the resources needed from the mainframe to the server.

8

General / Re: CMOD in the Cloud

« on: November 01, 2023, 10:28:33 AM »

What's the consensus of your customers in the Cloud? Level of responsiveness by IBM to issues, High Availability, application response to query and return documents via ODWEK, Costs, interface with a mainframe environment, being able to run line commands (and what exactly it takes besides -h parm), difficulties in migrating content stored in TSM to Cloud? IBM has already informed us we can't use TSM in the cloud. CMOD is a Tier 1 app in my shop that has to be available 24X6.5 with a replicated environment for DR/BR and recovered within 24 hours. Security is also a BIG issue being that we are a health insurance provider so we deal in PHI and we have it stored in CMOD. Any honest feedback is appreciated.

9

General / CMOD in the Cloud

« on: October 19, 2023, 07:51:33 AM »

Anybody in the group using CMOD in the Cloud yet?
We're running OD Multi-Platforms in a RHEL7 environment and the Unix/Linux engineers are informing us that the servers will be going into extended support next year until June 2025.
The question we're wrestling with is whether to stay on prem or go to the cloud. IBM documentation seems a little thin in the area of things like feature comparison between the cloud and on prem solutions, unless there is none.
CMOD is considered a Tier 1 mission critical application in my organization so remaining on RHEL7 past June of 2024 is considered 'not suitable' so I guess I have my goal for next year.
Input from the group would be appreciated.

10

Report Indexing / Re: Issues with PPDs + Resources

« on: August 09, 2023, 05:37:44 AM »

FWIW for the few applications I have using PPD this is what I have in the Indexer Information Tab

Indexer is PDF

Details
INDEXTSTARTBY=1
RESTYPE=ALL
INDEXMODE=INTERNAL

There's been no problems reported.
I don't use the BOOKMARKS or REMOVERES. Those were items The above parameters were taken directly from Bud Paton's PDF Indexing presentation that I attended in Chicago in 2015. I'm no PDF expert but I only ever used REMOVERES when using the X,Y coordinate method for indexing and load. I pushing my new PDF documents into using PPD.

11

MP Server / Question Setting Up LDAP & SSL Authentication for Windows Clients on CMOD V10.5

« on: April 20, 2023, 06:07:40 AM »

Has anyone set up LDAP/AD authentication through SSL for the Windows Client only on a MultiPlatorm installation?
I'm a mainframer with 17 years experience supporting CMOD in our environment and I'm tasked with authenticating the few users, less than 1k, that retrieve documents using the Windows (Thick) Client. (It was never intended but....)
I have to run the GSKit commands to set up the Key DB and Stash files. I assume I'll have to run them as root but root does not own CMOD. We changed that years ago. Will the resulting files have to be owned by the CMOD owner OR will I have to change permissions? If so what should I look for.
I open a case with IBM but they say that they can't answer that type of question (which I consider a how-to question but okay)  and I have to likely pay for Lab Services help. Not going to happen.
Any suggestions would be helpful.
Also I found that I am missing ARSLDAP.INI in my installation, likely because this server has been upgraded from the original install of 9.5 to 10.1 and now 10.5. I'm waiting to see what IBM says about this missing INI file. Does anyone know if I really need this INI?

12

MP Server / Re: TSM Error:ANS1035S (RC406) Options file '*' could not be found... *SOLVED*

« on: November 23, 2022, 07:50:07 AM »

The root cause was my server admins updated the IBM licensing agent on the 2 non-prod servers and that changed the permissions to libApiTSM64.so. IBM support traced that problem after I called to escalate my case with the duty manager.  I worked with my server admins this morning and they basically compared what was on my prod server with what was on the non-prod servers and found the problem immediately. Once the permissions were fixed I was able to stop and start arssockd then load documents to TSM on both servers.
The TL promised to notify me when are ready to update my production server and went so far as to make sure the licensing update wouldn't update the permissions.

13

MP Server / Re: TSM Error:ANS1035S (RC406) Options file '*' could not be found...CMOD Down

« on: November 22, 2022, 09:42:31 AM »

That's the problem. This system has had few if any changes recently. I upgraded from 10.1 to 10.5 late in 2021 and that was AFTER my storage guy upgraded TSM to the compatible version with 10.5.
I'm good with posting diagnostics if you give me the complete command of what you need.

14

MP Server / TSM Error:ANS1035S (RC406) Options file '*' could not be found...CMOD Down

« on: November 21, 2022, 10:38:28 AM »

On Friday one of my customers attempted to load 2 small AFP document files from the mainframe to my QA environments and both files took 88 load failed errors.
The system log provided this information:
429 TSM Error: ANS1035S (RC406)  Options file '*' could not be found, or it cannot be read., Return Code=406, Reason=0, File=arssmsms.cpp, Line=1603  Srvr->
I sent the error to my storage guy and he ended up requesting a server reboot. When the reboot occurred arssockd failed to start. I cannot start it manually. I'm wondering if anybody has run across this while I wait for IBM support to figure out the problem.
CMOD V10.5.0.4 running on a RHEL 7 server
DB2 V11.01.0406
Spectrum Protect (TSM) V8.1.12

15

MP Server / Re: arsjesd broken in 10.5.0.4

« on: April 20, 2022, 11:47:18 AM »

I'm running the 10.5.0.1 in 10.5.0.4 as a fix provided by IBM.