Messages

16

MP Server / Re: Weird Error: The application group >< does not exist

« on: April 27, 2018, 07:26:15 AM »

It gets interesting here. There are no spaces/unicode characters in the file name and when processed with the -g and -a option, the file gets processed as it should be - ARS4317I Processing successful for file >filename< 

Why this hypocrisy by arsload?

Regards,
AP

17

MP Server / Re: Weird Error: The application group >< does not exist

« on: April 27, 2018, 06:26:40 AM »

That doesn't run either and fails with the same error.

18

MP Server / Re: Weird Error: The application group >< does not exist

« on: April 27, 2018, 06:13:03 AM »

Thanks for responding, JD. Here is the command (invoked via a script and supposed to run as a daemon):

/ondemand/bin/arsload -I ARCHIVE -fv -t 3600 -B AG.APP.IGN.IGN.EXT -c /arstmp -d /arslocation/filestobeloaded > "/arslocation/logs/arsload.log$(date +%Y%m%d%H%M%S).txt" 2>&1

19

MP Server / Re: Weird Error: The application group >< does not exist

« on: April 27, 2018, 04:58:09 AM »

Thanks for responding, Ed. Yes, there is an input exit but that primarily deals with user validation and the user in my case is same across all reports.

20

MP Server / Weird Error: The application group >< does not exist

« on: April 26, 2018, 09:25:08 AM »

Greeting fellow ODUsers,

I am facing a strange and baffling error for the past three days. I set out to process 111 odd reports using the arsload daemon. While 107 of those got processed successfully, I am facing the following error for the remaining 4:

Code: [Select]

The application group >< does not exist or user >ADMIN< does not have permission to access the application group
That "><" is essentially weird because the appgroup in question does exist and ADMIN does have administrative permissions on it. The report format is standard across the 111 reports -

Code: [Select]

AG.APP.IGN.IGN.ARD
OS: AIX 7.1.0.0
CMOD: CMOD for Multiplatforms 9.5.0.9

What could be going wrong? Any help would be really appreciated.
Thanks and Warm Regards,
AP

21

OD/WEK & JAVA API / Re: Replacing ArsSVTInterface and Updating ArsWWWResult / ARS6009E

« on: December 27, 2017, 02:26:24 AM »

We managed to get a trace, in a bid to find the root cause, but that doesn't help much either. Here is what we saw (you can see some error codes, reason codes and status codes - not that they speak much to us):

apiP_RestoreHitFromDocId:Enter
52597:140237026785024 12/26/2017 04:54:35:565822 INFO ars3wapi.C(1771)apiP_RestoreHitFromDocId:Current state byte_buffer=Z27v2UO8TFuS1sR4DV/sNvnh0uQwGDiclxSAWkYP6d.[masked for confidentiality].....nNu

52597:140237026785024 12/26/2017 04:54:35:565826 FLOW arscsvht.c(2717)CsvRestoreHitFromDocId:Enter

52597:140237026785024 12/26/2017 04:54:35:565828 FLOW arscsvht.c(1931)CsvMaxDocIdLength:Enter

52597:140237026785024 12/26/2017 04:54:35:565830 FLOW arscsvht.c(1960)CsvMaxDocIdLength:Return len=3380

52597:140237026785024 12/26/2017 04:54:35:565833 FLOW arscsvht.c(2120)CsvP_ICCDecrypt:Enter

52597:140237026785024 12/26/2017 04:54:35:565843 FLOW arscsvht.c(2163)CsvP_ICCDecrypt:Return arccs return code=0,ARCCS_OKAY
52597:140237026785024 12/26/2017 04:54:35:565854 FLOW arscsvht.c(2926)CsvRestoreHitFromDocId:Return pCsvHit=00007f8b60031d38

52597:140237026785024 12/26/2017 04:54:35:565858 FLOW ars3wapi.C(1796)apiP_RestoreHitFromDocId:Return

52597:140237026785024 12/26/2017 04:54:35:565861 FLOW arscsvdc.c(560)CsOpenDoc:Enter
52597:140237026785024 12/26/2017 04:54:35:582160 FLOW ars3wapi.C(978)JNIDataCallback:Enter
52597:140237026785024 12/26/2017 04:54:35:582375 FLOW ars3wapi.C(1237)JNIDataCallback:Return (ArcI32)pSession->FileError=0
52597:140237026785024 12/26/2017 04:54:35:586724 FLOW ars3wapi.C(978)JNIDataCallback:Enter
52597:140237026785024 12/26/2017 04:54:35:586912 FLOW ars3wapi.C(1237)JNIDataCallback:Return (ArcI32)pSession->FileError=0
52597:140237026785024 12/26/2017 04:54:35:591277 FLOW ars3wapi.C(978)JNIDataCallback:Enter
52597:140237026785024 12/26/2017 04:54:35:591456 FLOW ars3wapi.C(1237)JNIDataCallback:Return (ArcI32)pSession->FileError=0
52597:140237026785024 12/26/2017 04:54:35:596109 FLOW ars3wapi.C(978)JNIDataCallback:Enter
52597:140237026785024 12/26/2017 04:54:35:596293 FLOW ars3wapi.C(1237)JNIDataCallback:Return (ArcI32)pSession->FileError=0
52597:140237026785024 12/26/2017 04:54:35:601007 FLOW ars3wapi.C(978)JNIDataCallback:Enter
52597:140237026785024 12/26/2017 04:54:35:601320 ERROR ars3wapi.C(1127)JNIDataCallback:ArcOS_tempnam failed pSession->szTempDir=/tmp pSession->szTempPrefix=52597-00007F8B7A2A7700
52597:140237026785024 12/26/2017 04:54:35:601328 FLOW ars3wapi.C(1129)JNIDataCallback:Return 3=3
52597:140237026785024 12/26/2017 04:54:35:631136 FLOW arscsvdc.c(836)CsOpenDoc:Return csv_rc=2,CSV_RC_CANCEL csv_msgid=0,CSV_MSG_NO_MESSAGE
52597:140237026785024 12/26/2017 04:54:35:631147 FLOW ars3wapi.C(515)apiP_setReturnCodeAndMessage:Enter
52597:140237026785024 12/26/2017 04:54:35:631175 FLOW ars3wcom.C(1174)CmGuiGetString:Enter

52597:140237026785024 12/26/2017 04:54:35:631210 ERROR ars3wapi.C(10957)Java_com_ibm_edms_od_ArsWWWInterface_apiGetDocument:Current state rtn.RC=2 extId=6009 pMsg=A cancel request was received during a server request.

52597:140237026785024 12/26/2017 04:54:35:631215 FLOW ars3wapi.C(591)apiP_setReturnCodeAndMessage:Return
52597:140237026785024 12/26/2017 04:54:35:631218 FLOW ars3wapi.C(11138)Java_com_ibm_edms_od_ArsWWWInterface_apiGetDocument:Return session id=140236591238320 (irc)=1
52597:140237026785024 12/26/2017 04:54:35:636788 FLOW ars3wapi.C(5859)Java_com_ibm_edms_od_ArsWWWInterface_apiLogoff:Enter session id=140236591238320
52597:140237026785024 12/26/2017 04:54:35:636795 FLOW arscsvlg.c(650)CsvLogoff:Enter
52597:140237026785024 12/26/2017 04:54:35:636813 FLOW arscsvfl.c(2146)CsvCloseFolder:Enter
52597:140237026785024 12/26/2017 04:54:35:636835 FLOW arscsvfl.c(2250)CsvCloseFolder:Return
52597:140237026785024 12/26/2017 04:54:35:638166 FLOW arscsvlg.c(790)CsvLogoff:Return
52597:140237026785024 12/26/2017 04:54:35:638178 FLOW ars3wapi.C(5896)Java_com_ibm_edms_od_ArsWWWInterface_apiLogoff:Return session id=140236591238320 (0)=0

Does anyone have an idea what it means? In my 10+ years of using ODWEK, I've never encountered this  Any help will be much appreciated.

Warm regards,
AP

22

OD/WEK & JAVA API / Re: Replacing ArsSVTInterface and Updating ArsWWWResult

« on: December 22, 2017, 03:39:10 AM »

The troubles just don't cease to exist. We upgraded ODWEK to 9.5.0.9 as advised (thanks Justin!) and then loaded a couple more DOCX and MSG files. Now, the strange thing is that, some documents of these types can be retrieved (a somewhat better scenario than before  ). E.g.  in a folder containing .MSG (Outlook message files), there are three documents and we can retrieve only two of them successfully. Similarly, in the folder for .DOCX documents (Word documents from Office 2007 onward), one document can be opened and the other can’t.

The [MIMETYPES] are set in arswww.ini as

Code: [Select]

o MSG=text/html
o DOCX=application/ms-word
 - For the failing documents, error is encountered in the

Code: [Select]

ODHit.getDocument() method (it returns null bytes)
 - Exception message for the failing documents is - 

Code: [Select]

com.ibm.edms.od.ODException: A cancel request was received during a server request.
 - Per CMOD message codes, it is error ARS6009E that advises you to look into System Logs in CMOD.
 - We referred to the System Logs in CMOD as well, but there is no corresponding error logged over there.
 - The failing documents can apparently be viewed from the Thick Client

Any assistance will be really appreciated. Thanks in advance,

Warm Regards,
AP

23

OD/WEK & JAVA API / Re: Replacing ArsSVTInterface and Updating ArsWWWResult

« on: December 20, 2017, 03:03:25 AM »

Thanks a lot, Justin!
Though we could not justify it, but we were also inclined to blame it on the MIME-types. As you advised, we'll go ahead and upgrade to 9.5.0.9. 

Thanks again!
Warm regards,
AP

24

OD/WEK & JAVA API / Re: Replacing ArsSVTInterface and Updating ArsWWWResult

« on: December 19, 2017, 04:30:14 AM »

Thanks to Justin for the documentation!
The process of updating the old API references was getting too tedious, so we did away with that code and added a crisper version of document retrieval (as prescribed in v9.5)  and thankfully it is working now (well, most of it).

In general, we're able to retrieve almost all the documents. For some documents, somehow, the retrieval from our application fails, citing - ODException: A cancel request was received during a server request and we end up getting null bytes for the document. This, apparently, is error ARS6009E (per manuals). Weirdly though, the retrieval of the very same document happens just fine through a standalone class. And in both cases, the docIDs come up differently.

The failing documents are .DOCX, .PPTX and .MSG files. I am thinking 'no' but would that have any bearing on the retrieval?

The jar used for the standalone class is the same as the one used in the application and the testing environment. Wonder what is missing 
Note: ODWEK version is 9.5.0.0, so the docIDs are not pre-encrypted and pre-base64encoded.

25

OD/WEK & JAVA API / Re: Replacing ArsSVTInterface and Updating ArsWWWResult

« on: December 07, 2017, 03:05:49 AM »

Wow! That's great, precisely what we were looking for. Hopefully this solves the issue. Thanks a ton, Justin.
Will let you know how the changes pan out.

Regards
Abhinav

26

OD/WEK & JAVA API / Re: Replacing ArsSVTInterface and Updating ArsWWWResult

« on: December 06, 2017, 03:47:18 AM »

Thanks a lot, Justin! I will surely go through the same. Hopefully, I'll get a solution.
EDIT: The documentation doesn't seem to have any info on the Arsxxxxx classes. Would you happen to have anything on that. Our code has numerous references to ArsWWWResult and that's bugging me

Thanks again.

27

OD/WEK & JAVA API / Error ARS6009E / Replacing ArsSVTInterface and Updating ArsWWWResult

« on: December 04, 2017, 04:33:31 AM »

Hello everyone,
We have a web application running  ODWEK 7.1.x (yeah, I know it's quite old, please don't judge me  ) connecting to CMOD 7.1.x. Thing is, we are trying to upgrade the setup. CMOD server upgrade was successful and we are able to use it perfectly through the Thick Client.

However, the web application that uses ODWEK for CMOD connectivity, uses classes - ArsSVTInterface and ArsWWWResultand it's there that we are having troubles. Now we could modify the application if we knew what actually these classes entail but we haven't found a single piece of documentation on these. The idea is to remove any references of the former (as IBM suggested) and update the code with correct usage of the latter.

Decompiling the classes doesn't give much of an insight. Could you please help me understand these classes, or suggest a workaround?

EDIT: Forgot to mention, CMOD server is on 9.5 and ODWEK intends to be there.

Warm regards,
Abhinav

28

MP Server / Re: Editable Index field/values in an AppGroup

« on: July 13, 2016, 06:07:11 AM »

Wow! That was easy 
Thanks a lot, Alessandro!!

29

General / Re: PDF Indexer

« on: June 24, 2016, 06:27:17 AM »

Hi Steve,
Do you have any specific requirement for using the PDF indexer? I mean you could use ACIF or Generic just as easily.

Regards
AP

30

MP Server / Editable Index field/values in an AppGroup

« on: June 24, 2016, 06:21:23 AM »

A warm hello to fellow ODUsers,

I need a little help. My client wants to make certain index fields/values modifiable in a particular app group - let's say fields InvNumber and InvAmt in a certain AG called InvoiceUpdate. These should be editable for a certain group only - say ZonalManagerGroup.

While I understand that this process would start somewhere from the AG permissions tab and/or the ARSAGPERMS table. But I am not sure where and how to begin it?

Any assistance will be appreciated. Please let me know if I haven't furnished any other required information.

Warm regards,
Abhinav

Edit: Forgot to mention: this is for CMOD on Multiplatforms v 9.0.0.3