Messages

46

Windows Client / Re: Single sign-on for client

« on: September 20, 2019, 06:46:10 AM »

We have built a "SSO ready" solution for a customer (custom arsusec exit). I write "SSO ready", since the customer has STILL not implemented a SSO solution (I think they are considering Kerberos).
If and when they do, our solution will accept a ticket as an input parameter, and this ticket will be verified vs the whatsitcalledthingamy-"ticket dispensing server" or whatnot. Today, we have a simpler algorithm in place for handling this (as they don't have any "real" tickets), and our solution works with the same number of parameters. ITs just the content today that is not real SSO.

So yes, it should be quite doable.

47

Content Navigator / Re: Is JAVA JRE Needed ?

« on: September 19, 2019, 07:54:44 AM »

Since no one has answered yet, I'll give it a go.
You DO need Java on the server. I am uncertain if the JRE is enough, or if you need the full Java "SDK" or Java Enterprise package. (Both are downloadable)

On the client side, you should to the best of my knowledge NOT need any form of java installed, UNLESS you want to use the old/deprecated Java applets for printing etc (DON'T! Use the HTML5 versions instead!!!).

I hope and believe that this is fully correct and helps you out.

48

MP Server / Re: OnDemand Authen Local User&Password with ARS_OD_AUTHORITY_FALLBACK parameter

« on: September 16, 2019, 04:17:42 AM »

Hi Teera,

The parameter should still be there:
https://www.ibm.com/support/knowledgecenter/en/SSEPCD_10.1.0/com.ibm.ondemand.administeringmp.doc/dodlp003.htm

https://www.ibm.com/support/knowledgecenter/en/SSEPCD_10.1.0/com.ibm.ondemand.administeringmp.doc/dodlp001.htm

Check the naming, in your post the "_LDAP" part is not in the parameter name, but I think it probably should be.

49

MP Server / Re: I just found an AG with no Segment Field...

« on: September 11, 2019, 05:33:54 AM »

I've had several cases of upgrading customers to 9.5 (was it?) and beyond. When the date format is changed from small_int to TIMESTAMP, the ARSSEG table gets zeroes or minus 1 as min/max values. This causes searches against affected Application Groups to return zero results (spooking the canola out of the customer  ), even though the data is safely stored in their systems.
There is a PMR about this, PMR 39507,140,846, where the activities to solve this is documented. But I guess many/some of you have already done this.

50

MP Server / Re: Manually retrieving a document?

« on: September 11, 2019, 05:21:43 AM »

Hi Matt,

You probably want to use the commands "arsadmin retrieve" and "arsadmin decompress". Here's the onscreen help for the latter:

arsadmin decompress
ARS1013I Usage: arsadmin decompress [options]
   Version:  9.5.0.9
   decompress Decompress a file
      -b <off> Offset to begin at.  (Default 0)
      -c <type> Document Compress Type
         'D' Disable Compression
         'F' OD77Lite Compression
         'H' OD77HW Compression
         'L' LZW12 Compression
         'N' No Compression
        'O' OD77 Compression (Default)
         'X' OD77LiteHW Compression
         'Z' LZW16 Compression
      -l <len> Length to end at.  (Default file size)
      -o <out_file> Output File
      -s <src_file> Input File
      -1 <trace_file> Trace file
      -2 <trace_level> Trace level

51

Other / OAIS support (ISO 14721)?

« on: September 11, 2019, 01:55:20 AM »

Hey, does anyone know if it is possible to make OnDemand OAIS compliant? (Or if it already is - where can I find proof of this?)
How much work would it take? Is IBM already looking into it?

Reference: https://en.wikipedia.org/wiki/Open_Archival_Information_System
(The OAIS/ISO 14721 costs half an arm and a quarter leg, plus hours of reading for those who are interested)

52

OD/WEK & JAVA API / Unload call

« on: October 26, 2018, 02:46:42 AM »

Hi all, maybe it's just me, but I'd like to have an ODAPI call that does Unload.
A swift way to remove botched loads without needing to have the thick OD client installed, nor need to file a case and send it to the OnDemand Administrator.

Has anyone found another smooth solution for this?

53

OD/WEK & JAVA API / Re: AFP2PDF Plus

« on: October 26, 2018, 02:43:26 AM »

Hej Håkan,

You can contact us at Apendo AB for some professional help if you like.

www.apendo.se

54

MP Server / Re: Large Migration + Codepage

« on: October 24, 2018, 12:56:33 AM »

Hi jsquizz,
I would say that it depends on how many documents are in the system. And of course a lot of other stuff, such as network bandwidth available, disk speed etc etc, but the fewer the # of docs, the more viable a retrieve/get plus load would be.

I am curious if you - or anyone else in this forum (ping @JD @Alessandro & co ) have by now performed a migration from <any Unix> to RHEL 7.X?
I am about to do it, and customer requests if there are any reference installations who have already done this.
Any RHEL 7.x is interesting, this particular customer wants to move to RHEL 7.5 or possibly 7.6.

55

MP Server / Re: PDF Indexer with large PDF files

« on: August 23, 2018, 08:54:44 AM »

I see that you have not yet received an answer to this, so I'll give you a partial one.

When I look at one of the OD systems I manage, we use "PagePiece Info" PDF indexing a lot for the bigger loads. We also try to divide big loads into batches of 20,000 or 50,000 documents each.
I'm sorry but we do not store Page Count for our batches, but a reasonable estimate would be somewhere around 1,5 to 2,5 on average pages per document.

The time needed to index these files are dependent on a lot of things, here are some:
what type of PDF indexing you use , how many fields you have defined, how complex the structure of the PDF file is (including compression, which should be avoided), (number of ) CPU(s and their) speed, amount of RAM available, how fast your disks are (to read the large files)... etc etc.

With the fairly small OD servers we have, and around a dozen fields defined, the indexer seems to handle about 100 documents per second. So a 20,000 doc batch takes about 200 seconds to index etc.
I am pretty sure that you can achieve much faster indexing rates with better hardware.

I hope this gives you a hint, and that someone else can give you a better answer.

56

MP Server / Re: ARS1400E

« on: August 23, 2018, 08:26:06 AM »

About the error itself. This seems to happen "always" when there is a failed load... at least on Windows-based systems, starting with V9.5.
Any time a load fails, it cannot be loaded again unless you do an Unload first. (OK, maybe not EVERY time....but it sure feels like that!)
So if 800 files fail, you have to do 800 Unloads first. That sux bigtime.
I have written two scripts for this, "BulkUnload.bat" (which accepts a file with a list of LoadIds to Unload) and "BulkUnfail.bat", which removes the ".Failed" extension from the ARD files, so that the Load Daemon can find and re-attempt loading of this again.

Here is a valid answer I found online, which explains why the problem occurs - and how to resolve it:

Answer by eandreasen (1) | Oct 05, 2016 at 02:15 AM

The reason for this error message is the new table arsloadwork which was created in V9.5 to prevent the same file from being loaded twice by inserting the AG, APP and the input file names into the table. It serves the intended purpose, except when the network is interrupted before arsload completes. In this case, a row is already written into arsloadwork, but the indexes have not be inserted into the AG data table. Before you attempt to reload the same file, you need to manually clean up the arsloadwork table, e.g,

delete from arsloadwork where agid=5328 and aid=5359 and "loadid ='5358-1-0-5650FAA-20160913033728-20160913033728-5359'"


Be careful with fiddling with the OnDemand DB tables though...  :-O

There is a big problem with this annoying error message. Sometimes, there is no corresponding MsgNum 88 in the system log, actually no trace at all in the System Log of the LoadId that "...has yet to be unloaded..."! These cases can however be unloaded by using this workaround:

1. Find and copy the LoadId from the NEW MsgNum 88 which you inevitably received when you tried to reload the file by removing the .Failed extension:
"... ARS1400E ... has yet to be unloaded.  Failed LoadId >5389-11-0-24944FAA-20180823000000-20180823000000-5390< was attempted to be loaded at approximately 2018-08-..."
2. Run arsadmin unload:
"D:\Program Files\IBM\OnDemand\V9.5\bin\arsadmin.exe" unload -g <YourApplicationGroup> -u YOURLOADUSER -p "D:\scripts\YourScriptsStashFile.stash" -h ARCHIVE -N -L <LoadId_You_Copied_In_Item_1_Above>

57

MP Server / Re: how to stop using TSM with CMOD?

« on: August 08, 2018, 05:55:35 AM »

If you only have 50 GB of data stored in the TSM, I would suggest that you:

• create new Application Groups (copy the existing ones) which use cache instead of TSM for storage
• export all your TSM-stored documents, and
• reload them into the new Application Groups.

If you use TSM for DB backups, you need to redirect your backup scripts and reconfigure OnDemand to backup DB2 to disk instead.

Once you have eliminated your need for TSM, change your ars.cfg ARS_STORAGE_MANAGER=TSM to "CACHE_ONLY" and you should be done.

58

MP Server / Re: Implied Hold vs HOLD -Any drawback?

« on: March 06, 2018, 09:01:08 AM »

Hi SV,

The Lockdown value of 16384 is correct. To my understanding, the Implied Holds are never stored in the ARSHOLDMAP table (as regular holds are), instead this high number uniquely identifies that there is an implied hold set on the document, without having to consult named table.

We have done some work trying to set regular holds on all documents. If you have several millions of documents, this is going to take quite a while.
Once we were done, we also experienced significant performance degradation, especially for arsdoc hold_release and arsdoc get, but also for arsadmin unloads.

So if you are happy with the Implied Holds, I'd suggest you go with them - it will put less burden on your system.

(Also, to my understanding, you ARE using another system to manage/initiate document retention - the system that generates or "masters" those "certain events" that you describe. Could it be your CRM system perhaps, or another LoB system? Go for Implied Holds.)

The only real drawback with Implied Holds that I have found so far is this scenario:
1. You remove the Implied Hold for a document, due to "a certain event" has happened.
2. You realise that you accidentally removed the hold from the wrong document (horreur!)
3a. The document gets deleted and you need to restore it. Bugger.
3b. You find out in time, before the document is deleted, but you can not restore the Implied hold because there is no command to do that.
(No, arsdoc hold_add -x IMPLIED_HOLD won't work. (Can't recall by heart if it is -x or -l <hold_name>))
4. To rescue the document you need to either:
 a. Add a regular hold to the doc, and an explanation why it has been set on this document, or;
 b. export and reload the document, so it gets a new Implied hold set on it, then delete/unload the original.

Good luck with ERM!

59

MP Server / Re: Index Exit should be placed

« on: January 24, 2018, 03:37:52 AM »

There are several different types of exits, but for many of them, they shall be put in OnDemand's /bin folder to work. Try putting it there instead, and restart arssockd.

60

MP Server / Re: How to index fully composed AFP with ACIF

« on: January 18, 2018, 05:40:10 AM »

Thanks JD. Tried your suggestion, as well as FORMDEF=F1FAL, but the error remains.

After carefully examining the output from arsafpd, I think it may be an error in the structure of the AFP file. The "MFC" section looks different in the erring position than it does in another instance of "MFC". So I have sent the file back to its originator for review. Will get back if we find (or confirm) the error.