Show Posts

This section allows you to view all posts made by this member. Note that you can only see posts made in areas you currently have access to.


Messages - Alessandro Perucchi

Pages: 1 2 3 [4] 5 6 7 8 9 ... 65
46
OD/WEK & JAVA API / Re: ODWEK middletier
« on: November 22, 2018, 10:25:39 AM »
Hello,

this is maybe too late for you and an answer, but it could be helpful for others.

So yes and no. but most probably yes.

Since the ODWEK API are in Java today, the most logical choice is to use an application server like tomcat, websphere, jboss, etc...

You still have the possibility to create a CGI in java, but the performance won't be great... so my advice would really be to go to the application server road.

47
OD/WEK & JAVA API / Re: ODWEK Middleware with Spring Boot
« on: November 22, 2018, 10:16:57 AM »
I've just come across your nice post.

Thank you to share your experience. I wanted to add some things that could be important.

First, if you are doing the caching of connections, be sure to cache the ODServer object, and NOT all the sub classes (like ODFolder, etc...). Because of how ODWEK Java API is created, and its use of JNI (C/C++ native libraries) if you don't do the caching on the ODServer object, you can have lots of problems on complex setup.

Second, from an IBM perspective, the only way ODWEK application is officially supported is to have ODWEK installed on your tomcat server. To package ODApi.jar in your war/ear/... is NOT officially supported, even if you package the native libraries and the codepage files and other stuff...

Cheers

48
OD/WEK & JAVA API / Re: odserver.login Was: ODWEK java api
« on: November 22, 2018, 10:09:03 AM »
Unfortunately you cannot with the ODWEK API connect to ICN and all the Desktop etc...
for that you need to use the JavaScript ICN APIs, or the ICN Java APIs.

You can find some information on the installation directory of ICN. and most importantly, you can find lots of information here:  https://www.ibm.com/support/knowledgecenter/en/SSEUEX_3.0.4/com.ibm.developingeuc.doc/eucdi000.htm

50
OD/WEK & JAVA API / Re: ODWEK java api
« on: September 11, 2018, 12:04:57 AM »
Thx Ed and Justin,

To have ODWEK replaced by JAVA API and keep the same functionality , what will be the estimated effort on doing this?
My customer is using the ODWEK interface intensively. Does the JAVA API give the same experience? Is someone having a screenshot or something like that?

One more question on something which is confusing me.

I see that the JAVA API is the replacement for ODWEK. But I also read that IBM Content Navigator is the way to go.
So both seem replacements for ODWEK. Do you have an opinion on this?

Thx.

Kind regards

Michel.


Just a word...
ODWEK is a library of many components:

- Old and deprecated CGI (arswww.cgi
- Old and depracted Servlet
- Java API
- Browser Plugins
- Misc other things, mainly docs and samples

That said the Java API is an API and will never 100% replace the CGI part without efforts.

I've done it in the past, because it was cheaper for customer to replace the CGI part with a custom made servlet, than to switch to ICN. I needed to replace the arswww.cgi with EXACTLY the same output of arswww.cgi, to not break the existing software that was parsing the existing html output... really quite a work to do...

It took us a 1 or 2 month (we were 2 doing the work). And we could do something like 70-80% of all the functionality of ARSWWW.CGI.
BUT it was a nightmare to handle the browser part. IE is not retrieving files in the same way than Chrome or Firefox... to handle that part it took us a lot of time.

At first we did ONLY the part the customers needed, and didn't implement the whole spectrum of arswww.cgi options. And after that parts were working as the customer expected, then we added progressibely the rest.

As Justin said, it would be much easier to use ICN instead, since a lot of struggle with browser, etc... are done natively with ICN!

51
OD/WEK & JAVA API / Re: Odwek getdocid in different format
« on: October 13, 2017, 03:33:41 PM »
Justin,

I have tested today a docid to read it by decoding it via base64... and it doesn't work.
Are you 100% of what you said?

I know for a fact, that the docid for security reasons they use the user ID for the user requesting the docid to "encrypt" the docid.
So if userA gets a docid, and gives it to userB, then userB cannot use the docid, since he is not userA.
For me this is like an encryption of the docid using the userA "key", and only userA can decrypt it, since he has his secret key.

Now what is the exact algorithm used, I have no idea. But from my simple test it doesn't seems to be base64, at least when I use base64 I receive an error saying that there are garbage characters.

If you have more juicy info, I am all hears :-D

52
OD/WEK & JAVA API / Re: Setup User Access Using ODWEK API
« on: October 13, 2017, 03:08:35 PM »
Just for info, ODWEK supports the exact functionality as ARSXML, you just need to pass your well formatted XML to the method ODServer.xmlparse(...) so you don't need to call the command line tool.

53
OD/WEK & JAVA API / Re: Finding Segment date serach field in AG
« on: October 13, 2017, 03:06:11 PM »
Just for info, until IBM doesn't change the format of the database, the field you search it the following for the segment field:

BITAND(MASK, 4)=4

54
OD/WEK & JAVA API / Re: odwek 9.5
« on: October 13, 2017, 03:04:40 PM »
IBM does not recommend that you copy the jar in your applications, especially to get support with a PMR.
Normally you need to install ODWEK (in the case of V9.5+ the full CMOD installation package), and in your application reference the ODWEK Jar and the native library (java.library.path)

Basically in AIX the jars are in /opt/IBM/ondemand/V9.5/www/api/ODApi.jar and the java.library.path for the native libraries are in /opt/IBM/ondemand/V9.5/www.


55
OD/WEK & JAVA API / Re: ODWEK 9.0 and ARSLOAD
« on: October 13, 2017, 03:01:44 PM »
Just one advice, the functionality of ARSLOAD from ODWEK V9.5 is NOT the full ARSLOAD command, just a subset of it.
It is like the Generic Index.
If you still need the full ARSLOAD functionality (ACIF Indexer, PDF Indexer, ...) then you must still use ARSLOAD command.

56
sorry for the late answer, since I don't work with CMOD anymore (well my old company still asks me for help :-D so I cannot lose my CMOD knowledge too quickly!!) ...

From your diagram it seems ok. I hope you could implement it.
Does it work, as the documentation explains?

57
Hi, Did you manage to install ondemand on RHEL 6.3? Is the operating system version stable? Tell us please

RHEL is a supported platform, and a had lots of customer (also the biggest customer in Switzerland) that use RHEL for CMOD. They have zero problems of stability.

58
MP Server / Re: Moving CMOD off of TSM server
« on: October 13, 2017, 02:51:39 PM »
Normally IBM recommend for CMOD to have the DB of CMOD on the same instance as CMOD itself.
This is for performance reasons.
Of course you can use the DB remotely (as the Oracle people loves to do for licensing reasons).

Concerning TSM, until V5.5 (the last version of TSM without DB2) it was common to have CMOD and TSM on the server.
Starting from V6.X and of course V7.X, it is not anymore advisable to use TSM on the same server as CMOD Server, especially because if you use DB2, that both the DB2 from CMOD and the internal DB2 from TSM could have conflict (there are tricks to avoid that conflict).
So IBM recommends to have CMOD Server and TSM as separate servers to avoid unnecessary problems/conflict.


So as Justin rightly said, you can simply give the hostname/IP of the TSM server by using the following entries in the ars.cfg file (or REGISTRY entries in Windows) file:

DSMI_DIR, DSM_DIR, DSMG_DIR   (location of your dsm.sys file)
DSMI_CONFIG, DSM_CONFIG and DSMG_CONFIG (location of your dsm.opt file)
DSMI_LOG, DSM_LOG and DSMG_LOG (location for your tsm log file)

and you don't need to use anymore the DSMSERV_DIR and DSMSERV_CONFIG entries.

59
MP Server / Re: Re: CMOD upgardes : v8.4.1 to v10.1 on Windows
« on: October 13, 2017, 02:42:03 PM »
I am hearing conflicting stories about upgrading to 10.1

Based on what I am CURRENTLY hearing...

You would have to go from 8.4.1, to 8.4.3, to 8.5, to 9.0, to 9.5, to 10.1...but who knows.

I did recently an 8.5 to 9.5 and the only reason we had to take a hop and do 9.0, was because we were using RDF

If you don't have RDF, then you can go directly from 8.4.1 -> 10.1 without stop.
The only reason you want to do a stop, is about the clients needs.
If you have a lot of old stuff accessing your CMOD (with arswww.cgi, old Java Program with old requirement on Java/...) then you might need to stop before 10.1 in order to resolve the client problem...
That's why at a customer I needed to stop with CMOD Server V9 and ODWEK 8.5, in order that he could upgrade its client legacy with new versions before going to V9.5.
That's the real reason to do a stop a one version for CMOD Server... and if some guys pretend that you must do (if you don't have RDF) a stop a each version, ... they don't know what they are talking about, and you must avoid them at all cost! (I speak from my experience here :-D)

60
MP Server / Re: copying part of AGs to new server
« on: October 13, 2017, 02:36:02 PM »

One warning: Don't forget about resources and doc_name1 files they are not listed in index segments but rather in arsres. The doc_name1 are not listed at all in CMOD but are not vital, however nice to have  ;) the doc_names (in case of AFP or PDFs)

I would just put a word of warning here... if you see in TSM/Cache/... a file where it finished with a 1 like for example: 123FAA1, then I would not considere it as "nice to have" anymore, but I will copy it in the new system.
I have learned that CMOD use it from time to time for some actions/tests... therefore PLEASE consider these files as important as the Objects of your archive.

Pages: 1 2 3 [4] 5 6 7 8 9 ... 65