Topics

1

Other / Repair TSM misconfiguration

« on: March 09, 2020, 06:42:49 AM »

Hi,

We have set up the CMOD 'backend' for storage to be TSM.
We have 2 TSM servers (a primary and a secondary) with 'Node replication: primary -> secondary' enabled.
Unfortunately the person responsible for the TSM setup missed the "indefinite" flag for TSM retention time on the primary node.
This led to TSM discarding loads older than 750 days (without waiting for CMOD to order the removal) on the primary node and, not surprisingly, documents in the removed loads are no longer retrievable from a CMOD instance running against the TSM primary node.
Fortunately (I hope) we can fix this since the backup node was set up correctly visavi the "indefinite" flag so the file systems removed from the primary node still reside on the secondary (no CMOD instance has ordered removal of any files).

Is it possible to reverse the roles of the 2 TSM servers so the files on the secondary server will be replicated to the primary server and by magic and/or pure luck be accessible again from the CMOD instance running against the primary node?

Thanks in advance

Anders.

2

Report Indexing / Tips/advice on Storage management -- Load vs. Segment

« on: January 14, 2020, 03:23:59 AM »

Hi,
I'm fairly new at designing archives in CMOD, working in a group with more seasoned CMOD people.
I need some expert help when it comes to storage management since I disagree with my colleagues    .
I get files with documents that are to be archived. The files contain appr. 5000 documents each and each document has a "document-date". There are days when I get 200+ of these files and other days when I get none.
I have no issues when loading the files.
Most of the time, the "document-date" is in close proximity to the date I receive the file (i.e. today - [2..7]days).
Each document is to be stored in the archive for "document-date" + retention-time.
The "do it by the book" solution is to choose "Storage Management"-->"Segment" and mark the "document-date" with the segment property, which is what I proposed.
My colleagues on the other hand opted for a "this is how we've always done" solution, choosing "Storage Management"-->"Load" and extending the retention time by 2 months, well aware and excepting the risk that some document(s) might be expired sooner than intended.
They claim that ARSMAINT will clean expired documents a lot faster when "Storage Management" is set to "Load" since the whole "Load-Id" (5000 documents) expire at once whereas ARSMAINT will have to check each document individually if "Storage Management" is set to segment and be significantly slower and/or need much more resources.
I can't find any documentation supporting their claim but they tried "Segment" once (a long time ago)  and base their  recommendation on that experience.

So my questions are
does "Storage Management"-->"Segment" actually induce a "severe" performance/resource penalty over "Storage Management"-->"Segment" when ARSMAINT expires documents?
is there any official recommendation on when to choose "Load" over "Segment" or vice versa (apart from the obvious difference "Load-Id"  vs "Index" retention time calculation)?
 
Thanks in advance
Anders

3

WEBI interface / WEBI custom logout page

« on: October 20, 2017, 02:31:28 AM »

Hi all,
Anybody out there that can explain how I would customize the WEBi logout function?
I need to go to a completely differnt page than the 'ODLogon' page.

From the WEBiJavaScriptReference:

onLogout()

Provides a method that you override to perform application-specific logic after a user logs out of this WEBi object.
Important: No logic is provided for this method. Therefore, you must provide code to implement the desired logic. If you call this method without implementing the logic, no action is taken.


Thanks in advance!

4

OD/WEK & JAVA API / <Partially SOLVED> -Win 7 ODWEK 8.5.0.10 -- Error: Could not initialize ICU

« on: September 07, 2015, 06:14:47 AM »

Hi,

No matter what I try on my Windows box, I keep getting this error when trying a simple test program from RAD v 9.1.

In my RAD project I include c:\opt\ODWEK\api\ODApi.jar and mark it for export

I'm using IBMs java from  a Websphere 8.5 installation
.....\AppServer8.5\java\bin\java
java -version gives
java version "1.6.0"
Java(TM) SE Runtime Environment (build pwi3260_26sr8fp3-20141218_02(SR8 FP3))
IBM J9 VM (build 2.6, JRE 1.6.0 Windows 7 x86-32 20141211_226933 (JIT enabled, AOT enabled)
J9VM - R26_Java626_SR8_20141211_2359_B226933
JIT  - r11.b07_20141003_74578.05
GC   - R26_Java626_SR8_20141211_2359_B226933
J9CL - 20141212_226933)
JCL  - 20141216_01

I have -Djava.library.path=c:\opt\ODWEK\85;C:\opt\ODWEK\8.5\lib32 (tried with and without trailing slashes)
My Win PATH statement has been updated with c:\opt\ODWEK\85;C:\opt\ODWEK\8.5\lib32 (tried with and without trailing slashes)

I've even tried (desperate) with the Win PATH/java system setting with all the ICU dlls i.e
c:\opt\ODWEK\8.5\lib32\icudt44.dll;c:\opt\ODWEK\8.5\lib32\icuin44.dll;c:\opt\ODWEK\8.5\lib32\icuio44.dll;c:\opt\ODWEK\8.5\lib32\icule44.dll;c:\opt\ODWEK\8.5\lib32\iculx44.dll;c:\opt\ODWEK\8.5\lib32\icuuc44.dll;c:\opt\ODWEK\8.5\
to no avail :-(

What am I missing??

TIA
/Anders

5

OD/WEK & JAVA API / ODWEK 8.5 installation problem CentOs 64-bit

« on: September 07, 2015, 01:02:05 AM »

Hi all!
I'm trying to install ODWEK for Linux in a Virtualbox virtual machine (Host Win7 64-bit, guest CentOS 64-bit).
The installation program
sudo ./odweklinux.bin -i console
Preparing to install...
Extracting the JRE from the installer archive...
Unpacking the JRE...
Extracting the installation resources from the installer archive...
Configuring the installer for this system's environment...
Launching installer...
Exception in thread "main" Preparing CONSOLE Mode Installation...
===============================================================================
Choose Locale...
----------------
    1- Deutsch
  ->2- English
    3- Español
    4- Français
    5- Italiano
    6- Português  (Brasil)
CHOOSE LOCALE BY NUMBER: 2
=======================================================
Installer User Interface Mode Not Supported
Unable to load and to prepare the installer in console or silent mode.
=======================================================

And I have been 'forced' to add some 32-bit rpms to get this far (since the installer launched is a 32-bit jre), libXtst and its dependent package(s), libc and some more that I can't recall. I'm guessing that I'm still missing one (or more) 32-bit packages that Installanywhere relies on.

Does anybody have a list of required rpms for installAnywhere used by the odweklinux.bin program?

the /tmp/odweklog.txt reports the followin error:

Selected Locale = English
XMLScriptReader: unable to parse the provided script file.  File may have been invalid...
java.lang.NullPointerException
        at ZeroGfg.a(DashoA10*..)
        at ZeroGfg.b(DashoA10*..)
        at ZeroGfh.a(DashoA10*..)
        at ZeroGfe.a(DashoA10*..)
        at ZeroGfg.a(DashoA10*..)
        at com.zerog.ia.installer.LifeCycleManager.t(DashoA10*..)
        at com.zerog.ia.installer.LifeCycleManager.j(DashoA10*..)
        at com.zerog.ia.installer.LifeCycleManager.f(DashoA10*..)
        at com.zerog.ia.installer.LifeCycleManager.a(DashoA10*..)
        at com.zerog.ia.installer.LifeCycleManager.a(DashoA10*..)
        at com.zerog.ia.installer.Main.main(DashoA10*..)
        at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
        at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:79)
        at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
        at java.lang.reflect.Method.invoke(Method.java:618)
        at com.zerog.lax.LAX.launch(DashoA10*..)
        at com.zerog.lax.LAX.main(DashoA10*..)
Unable to load the script.
SHUTDOWN REQUESTED

Please advise
/Anders

6

OD/WEK & JAVA API / Restful implementation with ODWEK

« on: August 27, 2015, 06:58:52 AM »

Hi all,

Do any of you have an example of a restful web service (non-commercial) built on top off (using) ODWEK to primarily get documents from CMOD.

TIA
/Anders