Messages

1

MP Server / Re: [BUG] Error while removing app from folder causing crash of CMOD frequently

« on: December 14, 2022, 03:26:18 AM »

Hi,

Just FYI - newest version 10.5.0.5 still has this issue.

2

MP Server / Re: [BUG] Error while removing app from folder causing crash of CMOD frequently

« on: September 01, 2022, 09:53:17 AM »

On my previous post I just give procedure to recreate problem with new CMOD objects.

Real situation I had on production with already defined objects and a lot of data loaded to these objects.
On production I have many applications with this problematic AG. To recreate problem only 2 apps is enough.
So, what i did on production was - add new application to AG and then remove it from folder.

So, my question is - how to fix the data to have possibility to remove application from folder without crash.
I believe it is possible to do it with adding alias to first application without alias.
It is not possible to do such thing from CMOD admin tool AFAIK. Or maybe I am wrong?
If I am not wrong then I am looking for a fix using db values manipulation.

3

MP Server / Re: [BUG] Error while removing app from folder causing crash of CMOD frequently

« on: August 31, 2022, 11:46:35 PM »

new app group
two new applications - first without alias, second with alias
new folder containing this app group - byt default it contains both applications.

CMOD will crash when remove application with alias from folder. And it will crash at every access to this folder later.

4

MP Server / Re: [BUG] Error while removing app from folder causing crash of CMOD frequently

« on: August 30, 2022, 06:01:08 AM »

Hi again,

Does anyone has some procedure to assign ALIAS to application without alias?

5

MP Server / [BUG] Error while removing app from folder causing crash of CMOD frequently

« on: August 25, 2022, 05:54:54 AM »

Hi,

We have CMOD on Linux Redhat:
Version:                      10.1.0.11
Operating System:             Linux
Operating System Version:     #1 SMP Wed Jun 15 08:55:08 UTC 2022.3.10.0-1160.71.1.el7.x86_64
Database:                     DB2
Database Version:             11.01.0406

PMR for this was rejected because we have unsupported version 10.1 - we cannot upgrade to 10.5 because we have some relations to old CMOD on mainframe.

Short description of this bug:
App group has 2 or more apps. One app has ALLIAS empty - standard for first application.
Folder contain this app group with all applications included.
Action to generate CMOD crash: Remove from folder application with non empty alias.
Later CMOD will crash again for every try of use this folder.

Longer description at end of this post.

This is just for Your information.
If someone can register this problem to IBM then please do that.

Regards
Rafal

CMOD breakdown 2022-08-23

Procedure to recreate problem:
App group: rafal_test
1.   Create first application – to create first application you don’t have to have field marked in AppGroup as “Application ID field”, so I created new application rafal_test_def
2.   Create second application – to do that You have create field marked in AppGroup as “Application ID field”- so:
a.    I added field “cmodappid”, and I added mapping “PDF/PDF”
b.   Then You can add second application “rafal_test_PDF” with Identifier “PDF”
3.   Create folder “rafal_test” for “rafal_test” app group – by default this folder will contain all applications.
4.   Now we have a setup ready to recreate problem – we have two applications
a.   One without ALIAS
b.   Second with ALIAS = “PDF”
5.   To recreate error we have to update our “rafal_test” folder and remove application having ALIAS = “PDF”. Result will be  - crash of CMOD library server
Now every time You will open “rafal_test” folder (does not matter how) CMOD library server will crash again.
Some info about crash from kernel ring buffer (dmesg | grep arssockd) :
[1922646.654469] arssockd[22471]: segfault at 0 ip 0000000000a7611c sp 00007f85cb3f6388 error 4 in arssockd[400000+bc3000]
[1922909.368816] arssockd[24071]: segfault at 0 ip 0000000000a7611c sp 00007f0b5cfed388 error 4 in arssockd[400000+bc3000]
[1923183.589816] arssockd[25014]: segfault at 0 ip 0000000000a7611c sp 00007effd3bf7388 error 4 in arssockd[400000+bc3000]
Today I know how to fix this issue using manual delete of records from CMOD tables:
1.   Check Your AppGroup id:
select * from ARSAG where NAME = 'rafal_test'
rafal_test      13401

2.   You have to delete records from ARSAG2FOL table having AID <> 0 – I guess this operation is restoring situation before removing application having ALIAS = “PDF”

select * from ARSAG2FOL where AGID=13401
delete from ARSAG2FOL where AGID=13401 and AID <> 0;

6

MP Server / Re: ARS2089E error while extracting with arsdoc get

« on: July 20, 2021, 01:24:41 AM »

I'm guessing - and this is just a guess - that some storage set has been inadvertently deleted.

If you can figure out the node id and do a mapping to the arsnode table then that may signal to you in advance what to avoid retrieving.

I checked that it is not a problem with whole storage node - 99,9% objects in this storage node are fine - only few objects has this problem.

7

MP Server / Re: ARS2089E error while extracting with arsdoc get

« on: July 15, 2021, 06:23:21 AM »

When i discover which objects (DOC_NAME in segment tables) has this issue then I can ommit them and extraction will work fine.

I have two problems
1. I would like to find a new easier way to find documents/objects which are not available without running arsdoc get plenty times.
2. I would like to know if problematic documents can be rescued or not.

8

MP Server / Re: ARS2089E error while extracting with arsdoc get

« on: July 15, 2021, 12:48:24 AM »

this was in 2010 - so, I am not interested in understanding nature of this problem.
I just need rescue this documents if it is possible .

9

MP Server / ARS2089E error while extracting with arsdoc get

« on: July 14, 2021, 05:26:31 AM »

hi,

Currently I am doing some 2010 year extractions from our CMOD on z/OS - version 9.0.0.6 (DB2 + data in OAM files).
Document type - AFP.
I have issue while arsdoc get - error is "ARS2089E Information has been modified on the server.  Please logoff, logon, and retry the operation."

Some log details:
2021-07-14 13:57:10.868179: ARS6063I Searching for documents in 'NLPDK-PENSOVER' ...
2021-07-14 13:57:10.868200: ARS6117I Querying database with SQL string '5;DATO,DATO,DOC_NAME,DOC_NAME,DOC_NAME;'2010-08-09','2010-08-09','','','';WHERE (DATO BETWEEN ? AND ?) AND DOC_NAME NOT IN (?,?,?) '
2021-07-14 13:57:17.757775: ARS6084I Search successful
2021-07-14 13:57:17.757879: ARS6107I 331 document(s) have been queried. Retrieving 331 document(s).
2021-07-14 13:57:17.950935: ARS2089E Information has been modified on the server.  Please logoff, logon, and retry the operation.
2021-07-14 13:57:17.954641: ARS6026I arsdoc completed.

I was able to find problematic objects by reducing search period and then adding more conditions to SQL query to have less hit ratio.
But it is time consuming way to find problematic objects.

Q: Is there a faster way to find documents which has this issue?

While trying to open this document in CMOD Client we also have message: "Information has been modified on the server.  Please logoff, logon, and retry the operation."
Offcourse logoff and logon does not help .

I checked logs while loading these documents and this issue is connected with following db2 error:
03-06-2010 17:28:52   US00600        661504   Error   No       13   DB Error: äDB2 FOR OS/390åäODBC DRIVERåäDSN08015å   DSNT408I SQLCODE = -911, ERROR:  THE CURRENT UNIT OF WORK HAS BEEN ROLLED BACK            DUE TO DEADLOCK OR TIMEOUT.  REASON 00C9008E, TYPE OF RESOURCE                   00000302, AND RESOURCE NAME ARS   
This error is occuring at the same moment while loading problematic documents.

Q: Can we somehow "rescue" this documents?

Regards
Rafal

10

MP Server / Autostart of CMOD library server on RHEL v7

« on: July 03, 2020, 07:43:03 AM »

Hi,

In RHEL v7 we have new autostart manager - systemd.
I am trying to setup starting of CMOD library server in systemd - I checked lot of options and I did not succeeded.

Can You give me some advices to setup this?

CMOD library server is started in specific way - there is another process started in background.
Here:
https://www.freedesktop.org/wiki/Software/systemd/Incompatibilities/
I found this information:
"If systemd doesn't know which PID is the main PID of a service, it will not be able to track its runtime, and hence a service exiting on its own will not make systemd consider it stopped. Use the Red Hat "pidfile:" syntax in the SysV script header comment block to let systemd know which PID file (and hence PID) belongs to your service. Note that systemd cannot know if a SysV service is one of the kind where the runtime is defined by a specific process or whether it is one where there is none, hence the requirement of explicit configuration of a PID file in order to make systemd track the process lifetime. (Note that the Red Hat "pidfile:" stanza may only appear once in init scripts.)"

Maybe this is a problem?

Regards
Rafal

11

MP Server / Re: Can CMOD v9.5 cooperate with TSM v8?

« on: February 03, 2020, 08:16:36 AM »

Of course, I feel the need to re-iterate that CMOD v9.5 goes out of support April 30th, 2020 -- so you should be focusing on your move to v10.1, and not supporting a version that's going out of support! 

That's why I created this topic - we are analyzing different scenarios of upgrade to 10.1
Thanks for replies

12

MP Server / Can CMOD v9.5 cooperate with TSM v8?

« on: January 30, 2020, 02:07:19 AM »

Hi,

Here:
https://www.ibm.com/software/reports/compatibility/clarity-reports/report/html/softwareReqsForProduct?deliverableId=1363650145499

we can find information that CMOD 9.5 can work with TSM v6 and v7.
But what about v8 - is CMOD 9.5 able to work with TSM v8 (new for TSM - IBM Spectrum Protect).

Regards
Rafal

13

MP Server / Re: ARSMAINT is not removing expired documents from cache on object server?

« on: December 05, 2019, 04:58:19 AM »

I did some experiments with running ARSMAINT on library server and then on object server (servers are separated - LS is one host and OS is another) and I have following conclusion:
- ARSMAINT is maintaining cache on server on which script is run
So, If You run ARSMAINT on library server then it will maintenance cache on library server and cache on object server will not be maintained
Is that correct?

14

MP Server / Re: ARSMAINT is not removing expired documents from cache on object server?

« on: December 03, 2019, 03:48:14 AM »

Well, it means what it says...

Yes, it was issue with permissions - after fixing this arsmaint for cache works well
Thanks for help

15

MP Server / Re: ARSMAINT is not removing expired documents from cache on object server?

« on: November 29, 2019, 08:41:47 AM »

I have an additional question: are data in cache compressed?