Messages

16

MP Server / Re: Non-Root Install - Anyone doing this?

« on: February 20, 2019, 04:32:00 AM »

I have done non root implementation of CMOD for the last 15 years, since it was possible to do it. And without any problems.
I would say that now in Switzerland no CMOD is using root account anymore, or at least 99.99% of all customers :-D I don't know all of them!

Now the installation with non-root, as you have found out, you cannot change the installation path. It will ALWAYS be $HOME/ibm/ondemand/Vxxxx or $HOME/IBM/ondemand/Vxxx on AIX.
Of course you can trick with the silent installation file, BUT all upgrades, etc... won't work. This is really sad and InstallShield is not really flexible in that area... I would like that IBM ditch that install software, but one can dream!

Nevertheless, what I also found is that if you install in a non standard installation path (I mean the official /opt/ibm/ondemand/Vxxx or /opt/IBM/ondemand/Vxxx), and it doesn't matter if you install with root or non-root ( $HOME/ibm/ondemand/Vxxx or $HOME/IBM/ondemand/Vxxx is NOT standard installation path for OnDemand strangely enough...), then you need to use the variables:

ARS_INSTALL_SERVER_Vxxx_DIR
ARS_INSTALL_ODWEK_Vxxx_DIR

And be careful that ARS_INSTALL_SERVER_Vxxx_DIR = ARS_INSTALL_ODWEK_Vxxx_DIR.

where xxx = 101 for OD V10.1
xxx = 95 for OD V9.5
xxx = 90 for OD V9.0
xxx = 85 for OD V8.5

Otherwise, I have found that some actions like all tools based on ODWEK (ICN) and some internal tools of CMOD, are lost in space... because for some reasons they still look at the /opt/... standard path...

Regards,
Alessandro

We are analyzing everything from a security standpoint. And just getting much push-back about installing a binary in /home/archive(or whatever instance name

It's good to note that it looks in /opt, thank you for that. We were looking at doing it on a different mount such as /prodInstall/ibm/ondemand/.....

Well the $HOME is not necessarly /home/xxx but the home directory of your installation, so it could be /prodInstall with the user "prodinstall" (for example) which has his home directory as /prodInstall
then you can give other users the access to it, like the user "cmod". Set the correct variables, and DO NOT FORGET the permissions (https://www.ibm.com/support/knowledgecenter/en/SSEPCD_10.1.0/com.ibm.ondemand.installmp.doc/accountslin.htm) and that would be :
- $ODInstallDir/bin/arslog
- $ODInstallDir/bin/arsprt
- previously also $ODInstallDir/bin/arsrdprt
- don't forget $ODInstallDir/config/ars.ini

So that the other user can use your prodinstall installation :-D It is basically like the CMOD Documentation where you use root to install the product, and then use a non-root user to run your instance.
but here you install with user X and use a none-root, none-X user to run your instance!

Just my 0.0002$ !

17

MP Server / Re: Unable to store object Failure

« on: February 20, 2019, 04:23:03 AM »

Hi guys, yes I can confirm this issue as well.

Our setup is CMOD on AIX with TSM on AIX accessing ECS via CAS API.

02/20/19   08:10:19      ANR2547E A Centera device (5) reported error "Unknown error (transid='sb002017/9008600/WRITE_BLOB'),FP_SERVER_-ERR" during command BlobWrite. (SESSION: 702829)
02/20/19   08:10:19      ANR0523W Transaction failed for session 702829 for node NODE01 (CMOD) - error on output storage device. (SESSION: 702829)
02/20/19   08:10:19      ANR0514I Session 702829 closed volume 00003C41.CNT. (SESSION: 702829)
02/20/19   08:10:19      ANR0403I Session 702829 ended for node NODE01 (CMOD). (SESSION: 702829)


After a re-submit all worked well.
Cheers,
 N.

What a cr@p... so ECS is maybe not a so nice replacement of Centera apparently...

Are there other solutions that "works" ?

18

OD/WEK & JAVA API / Re: What is your AFP to PDF Transform of choice?

« on: February 16, 2019, 03:26:37 AM »

Starting from next week I will look to transform AFP to PDF using ISIS Papyrus. I will need to write like a webservice to run the afp2pdf conversion script from ISIS Papyrus.

I will keep you inform if it is "slow" and without problem, or not.

19

MP Server / Re: Error running ARSXML export.

« on: February 16, 2019, 03:19:07 AM »

When we migrated from an 8.5 system (windows) to a 9.5 system(z/OS) I used ARSXML with a lot of manual manipulation of the xml export, including storage, to get the items to be defined correctly.  Seemed no way around it at the time.

I think that's my only option at this point sadly. Instead of trying to figure out why arsxml keeps crashing, on an old version, on servers that are going away. Thanks for the feedback

I have found that sometimes, old servers have not nice configuration of AG/APP/Folders for some reasons... that the admin was tolerating at one time, and then no more, but the db was "corrupted" slightly that you don't see the problem in the day to day production, but only when you do export such quirks appears.
And doing what you need to do is a wonderful way to clean up things.
BUT between XML from V8.5 and V9+... you have a lot work manual work to do, or script to do in order to convert from one format to another.

And don't worry, you could upgrade from CMOD V8 -> V10 in one shot without problems. The upgrade process is quite perfect in that area.
The only moment you might need to go to V9 is only if you use ODF/RDF.

Regards,
Alessandro

20

iSeries / Re: script to update storage set

« on: February 16, 2019, 03:13:34 AM »

Thanks jsquizz, I am not exporting to a new server. I just have to update the app group with new storage set

Try this- I just did this last week..

Modify your storage set.
Add a new storage node
Select your *primaryNode, uncheck "load data"
Select your new node, check "load data"

You should be set..it worked for me...I was able to retrieve data from both nodes.

I agree with jsquizz, that's the way to do it.

21

Report Indexing / Re: APP GRP Field length

« on: February 16, 2019, 03:11:33 AM »

Well to be honest, if I have such a change of length in a string field in CMOD, I change simply the size of the string in the database (table arsagfld), close the current segment table, and voila.
As long as IBM doesn't change that table layout. There are no problems, if you only increase the size.
Of course if you want to change old entries in the old segment tables, then... you need to play with alter tables, and so on.

In all cases, Testing Testing is your friend, as this method is totally unofficial :-) and not supported! But works like a charm!!!

Regards,
Alessandro

22

Other / Re: Upgrading TSM using Centera

« on: February 16, 2019, 03:06:46 AM »

It's extremely rare that I disagree with Alessandro...  but today is that day. 

I like arsdoc get / arsload because it gives you option to fix a lot of silly mistakes in the App Group config...  Expiration types, Segment size, field lengths, update date types, etc.    There are a lot of ways to improve an AG & App config when you do that -- which you can't do with Alessandro's method.

I agree in your disagreement!! :-D

I mean, if you want to do a quick 1:1 migration, then my way is the fastest of all. And it works. I've done it countless of times.

Of course, if you want to change quirks in the AG definition, then I would go your road without thinking a second!!! :-D

All depends on what you want to do.

Regards,
Alessandro

23

MP Server / Re: Non-Root Install - Anyone doing this?

« on: February 16, 2019, 03:04:28 AM »

I have done non root implementation of CMOD for the last 15 years, since it was possible to do it. And without any problems.
I would say that now in Switzerland no CMOD is using root account anymore, or at least 99.99% of all customers :-D I don't know all of them!

Now the installation with non-root, as you have found out, you cannot change the installation path. It will ALWAYS be $HOME/ibm/ondemand/Vxxxx or $HOME/IBM/ondemand/Vxxx on AIX.
Of course you can trick with the silent installation file, BUT all upgrades, etc... won't work. This is really sad and InstallShield is not really flexible in that area... I would like that IBM ditch that install software, but one can dream!

Nevertheless, what I also found is that if you install in a non standard installation path (I mean the official /opt/ibm/ondemand/Vxxx or /opt/IBM/ondemand/Vxxx), and it doesn't matter if you install with root or non-root ( $HOME/ibm/ondemand/Vxxx or $HOME/IBM/ondemand/Vxxx is NOT standard installation path for OnDemand strangely enough...), then you need to use the variables:

ARS_INSTALL_SERVER_Vxxx_DIR
ARS_INSTALL_ODWEK_Vxxx_DIR

And be careful that ARS_INSTALL_SERVER_Vxxx_DIR = ARS_INSTALL_ODWEK_Vxxx_DIR.

where xxx = 101 for OD V10.1
xxx = 95 for OD V9.5
xxx = 90 for OD V9.0
xxx = 85 for OD V8.5

Otherwise, I have found that some actions like all tools based on ODWEK (ICN) and some internal tools of CMOD, are lost in space... because for some reasons they still look at the /opt/... standard path...

Regards,
Alessandro

24

Other / Re: Upgrading TSM using Centera

« on: February 07, 2019, 08:42:00 AM »

Normally when we change from storage A to storage B in CMOD, I do the following:

1) Create the target storage node in CMOD
2) Get all the object names from the segment table in CMOD (doc_name)
3) Export all the objects in storage A (if in TSM : dsmc retrieve /ODINST/ABC/) or from ondemand via "arsadmin retrieve". (don't forget the index files the doc_name with the 1 at the end)
4) import the objects from 3) via the command arsadmin store into the new node
5) change the pri_nid in the segment tables to match the new storage node.
6) remove the old storage node from OD
7) remove the old storage node

And that's the fastest way to do it, without the hassle to export all data (arsdoc get) and re-archive it via arsload, which works but it is slow...

25

MP Server / Re: Unable to store object Failure

« on: January 31, 2019, 01:19:08 PM »

Thank you for the feedback. We are planning in the next few month to migrate from Centera to the new ECS... what you say is quite frightening!
Since we don't use the arsload deamon feature, we can modify our scripts to check for such errors and try to reload x times...
but still I really don't like that... I hope this is only a "firmware" problem from ECS storage... ... ... ...

26

Other / Re: Upgrading TSM using Centera

« on: January 31, 2019, 01:10:52 PM »

I had a lot of customers with TSM and Centera. Centera is a beloved box in Switzerland, even if today Centera is "dead" and has been replaced by a new solution from EMC the ECS.
The company where I work now, are looking to migrating their Centera to ECS.

But back to your initial question, an in-place upgrade will work. Without any problems. If you use DB2 for CMOD, then you must be VERY careful because TSM use DB2 has an internal database, and having 2 separate DB2 instance in the same box is possible, but requires some careful planning and configuration.
Especially, per default DB2 wants to use the whole server memory! So if you have 2 DB2 doing that... I let you imagine the troubles! I know there is a setting in DB2 to tell him to use on X % of the server memory. If you do that in both DB2 (TSM and CMOD) then you are in a good place.
The other problem that could arise, is that you must make sure that CMOD doesn't use the wrong DB2 libraries... I had such problems in the past because of that.

Well that was for the in-place upgrade.

Now, to transfer from one TSM to another, like RHEL as suggested, I don't remember that a copy of a node was not possible if it was plugged with Centera.
I will need to ask the people who were involved in that in some of my previous projects or current workplace.
Unfortunately I am in holidays now until next Wednesday, so I won't be able to give you an answer before next week. So if someone has some experience, I hope he will be able to share, otherwise I will try to give something next week.

Regards,
Alessandro

27

MP Server / Re: Report Failed - AN ACIF STORAGE REQUEST WAS UNSUCCESSFUL - REQUEST SIZE 314 GETM

« on: January 31, 2019, 01:00:12 PM »

I don't know what to say, except is there a "buggy" character in your list that creates a problem in your user exit that you have developed?
Or something like memory leak? That would maybe explain why the storage request for 401 bytes was not possible, because the leak took the whole memory allocated.

Well this is only an idea...

28

z/OS Server / Re: Changing Maximum Rows

« on: January 31, 2019, 12:53:59 PM »

Yep, as Justin said use the admin client, OR the XML with arsxml.

Just be aware that after you change that value, CMOD will effectively use that value ONLY when you create a new segment table: close your active segment table, and then create a new one, or just load new documents.
Otherwise your current active segment table won't be able to use the new value.

29

MP Server / Re: Anyone using CMOD in a Docker container?

« on: January 31, 2019, 12:44:25 PM »

Ask, and Rob Russel will deliver!

https://www-01.ibm.com/support/docview.wss?uid=ibm10869710

A huge thanks to Rob for writing up this document.

-JD.

YEAHHHHHHHHHHHHHHHHHHHHHHHHHHHHHHHHHH!!!!!!!!!!!!!!!!!!

A Huge +1 to Rob !!!!

30

MP Server / Re: ARSSOCKD Crash when calling TSM.

« on: January 31, 2019, 12:42:08 PM »

Well putting aside the server is too old, if there was no connection with TSM in X years, then maybe the whole configuration with TSM is not correct anymore, not the correct port/server, etc...

Have you tried to check the dsm.sys and dsm.opt configuration? If they are still correct?