256
Report Indexing / Re: reports count
« on: March 25, 2019, 09:17:31 AM »
In the system log, I would search by-
msg num - 66
message %ODWEK%
msg num - 66
message %ODWEK%
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.
Just wrap the IBM CMOD arsload command with a for loop in your shell.Code: [Select]for i in metrics*.ind
do
j=${i%.ind}
arsload [options] $j
done
Hi all,
Wondering if anyone cares to share their insight, tips, and past experience on this.
As some previous posts state, I am looking into extracting data from an AIX system, using TSM/Centera, into a new system using Linux/ICOS. I am trying to put an actual timeframe on how long it is going to take to extract from AIX, and reload into Linux. I have the extract/reload process down mostly, but I am not sure where to start as far as coming up with solid dates.
There is a total of around 7TB of data to extract, totaling 200 Million Documents across 32 application groups. The totals of data in our app groups range from a few hundred MB, to 4.5 TB.
I understand there are SEVERAL variables to consider as far as this entire process goes, but does anyone have any suggestion as to how I can use our logs to actually put some realistic numbers to this.
Thanks in advance.
The only way to know for sure is to take an AG, and look how well it exports, and then how fast it imports.
From my experience, if you have an AG with lots of small documents, with lots of load ids, then it might take an awful long time, compared to an AG with big objects inside.
Since I've nearly never do an "arsdoc get" / "arsload" for such migration, I have very little details to give you.
<applicationGroup name="TESTTHIS3" >
<field name="LOCKD" type="Index" dataType="Small Int" uniqueID="false" hashSHA256="false" encryption="false" expireDate="false" log="false" userExit="false" partition="false" cluster="false" appIDField="false" reference="false" pageCount="false" documentSize="false" lockdown="true" CFSOD="false" FTI="false" updateable="false" />
</applicationGroup>
<applicationGroup name="TESTTHIS3" enhancedRetManagement="true" impliedHold="false">
</applicationGroup>
ARS7819E A value of 'enhancedRetManagement' for the applicationGroup attribute is not appropriate as the required feature is not enabled for this server.
ARS7762I Update of applicationGroup, TESTTHIS failed.
<applicationGroup name="TESTTHIS" enhancedRetManagement="true" impliedHold="false">
<field name="LOCKD" type="Index" dataType="Small Int" uniqueID="false" hashSHA256="false" encryption="false" expireDate="false" log="false" userExit="false" partition="false" cluster="false" appIDField="false" reference="false" pageCount="false" documentSize="false" lockdown="true" CFSOD="false" FTI="false" updateable="false" />
</applicationGroup>
Since we are trying to move from TSM to IASP , the TSM storage sets are in TSM servers, where as the IASP storage sets were in iSeries. So, we cannot do the above option.
Currently, we are planning to change the storage sets by logging to OnDemand Admin ->update the application group(to something like Appgrp_old), copy the Appgrp_old to new Appgrp -> select the new IASP storage set and change all the applications attached to the new app group .
lot of manual work!! Please help
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