Messages

256

iSeries / Re: Move data loaded in an AP to another different AP

« on: March 22, 2019, 05:56:55 AM »

Are you trying to load them, or ready them? If trying to load them --- try using arsload, with flag -X G, to force CMOD to use the generic indexer

Heres how I usually do it-

arsload -nvf -I instance -u admin -p *** -a app -g appgroup -X G filename.noextension

257

MP Server / SM Error 20 : ANS1361E - When running arsdoc

« on: March 20, 2019, 02:52:16 PM »

Hi all,

I am running a script that loops through a list of document names  / app groups, and runs an appropriate arsdoc get command.

I don't see any errors in my output- but I am seeing this in the CMOD system log..

SM Error: ANS1361E (RC61)   Session Rejected: The specified node name is currently locked
, Return Code=61, Reason=0, File=arssmsms.cpp, Line=1141  Srvr->server non-SSL<-

I checked TSM and the node is not locked..I checked the table for the application group and there are 52 individual unique doc_names. After running my retrieval, I see 104 files (52 index, 52 out..) so it looks like everything was retrieved.

Could this be a bug or something, I am not seeing any more issues...8.5.0.6 on AIX btw..

258

MP Server / Re: ARSLOAD Daemon + Force Generic Indexer?

« on: March 20, 2019, 09:26:26 AM »

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


This was pretty much the exact approach I was going to take. Thank you so much.

259

MP Server / Re: ARSLOAD Daemon + Force Generic Indexer?

« on: March 20, 2019, 06:14:06 AM »

Lovely. IBM suggested we do it this way 

Prior to me switching over to daemons, we had a script that would run and basically do an LS of a particular directory. The problem was that if the directory had like 300 files or so (Which wasn't experienced in the past..) There would be 300 seperate calls to ARSLOAD, causing all kinds of issues.

260

MP Server / ARSLOAD Daemon + Force Generic Indexer?

« on: March 19, 2019, 10:12:44 AM »

Hi All,

I am trying to do a reload of some data I retrieved..I am trying to load via daemon.

I have the .out/.ind/.ARD/.res, daemon is picking up the file.. But I am using the -X G flag to force the generic indexer. I have done this before when I do a single load but now it isn't working via daemon, the file is failing with an indexing error.

APK422S AN ERROR OCCURRED WHILE ATTEMPTING TO READ INPUT RETURN CODE 64.
APK448S INDEXING WAS REQUESTED, BUT NO GROUP 'TRIGGERn' NOR ANY 'FIELD' BASED ON IT WAS SATISFIED WITHIN THE PAGE RANGE SPECIFIED BY THE INDEXSTARTBY PARAMETER.
APK441I ACIF AT IM43P11 HAS COMPLETED ABNORMALLY WITH RETURN CODE 16.

Daemon-

arsload -B IGN.IGN.AG.APP.EXT -c /OD_installtmp/Extract -d /OD_installtmp/Extract -XG -f -t 60 &

Files-

metrics.276.AG.APP.ARD
metrics.276.AG.APP.res
metrics.276.AG.APP.out
metrics.276.AG.APP.ind

Is there some way that I have to trick the daemon into working with the -X G flags? Is it even possible?

Thanks in advance.

261

MP Server / Re: Changing retention for historical loads

« on: March 19, 2019, 08:29:31 AM »

Bumping this back to life.

Does anyone know if the "-d" flag will handle expiration of documents from ICOS based on AG retention settings?

My initial two approaches-

ICOS vault for each application group -> retention settings mirror the application group
One ICOS vault -> Never expire, and let "-d" take care of it?

Does anyone have benefits/drawbacks to each approach?

262

MP Server / Re: Listing of Load IDs with Index Values

« on: March 14, 2019, 11:05:42 AM »

Here is what I would do. Of course, I would fine tune this depending on your needs. Make sure you test all of this.

1) Get the exact table name for the specific app group-

db2 => select arsag.name, arsseg.table_name from arsag, arsseg where arsag.agid=arsseg.agid and arsag.name='AGNAME'

NAME                                                         TABLE_NAME
------------------------------------------------------------ ------------------
AGNAME                                                      TBL1


2) get a listing of the date, plan, doc_name from the table, and use where clause with the date you choose (in the arsdate format..)

db2 => select rdate, plan , doc_name from TBL1 where rdate = '17840'

3) export to excel, apply some filters to remove duplicates. Then toss them in an arsadmin unload

263

iSeries / Re: Move data loaded in an AP to another different AP

« on: March 13, 2019, 10:21:54 AM »

Look into arsdoc get, using the -X flag for load ID. Once you get the file retrieved, load it via arsload into the correct application group/app

264

MP Server / Re: Quantifying extract & reload

« on: February 28, 2019, 11:49:45 AM »

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.

Yeah, that's what i've been doing. I ran some tests loading / retrieving a few GB of data, and compared that to production.

My concern is the actual reload. Because we are not using TSM in our new environment, and loading a file that's already indexed quicker is obviously quicker than calling ACIF.

As I have mentioned before, I want to stand up a new environment and fix tons of inconsistencies between our objects. If that wasn't the case, I would look into the arsadmin approach that you have mentioned.

265

MP Server / Quantifying extract & reload

« on: February 26, 2019, 12:13:34 PM »

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.

266

MP Server / Re: Can't update enhancedRet with ARSXML?

« on: February 22, 2019, 10:59:36 AM »

Figured this out-

Field must be defined before setting enhancedRetManagement="true"

   

Code: [Select]

<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>

267

MP Server / Can't update enhancedRet with ARSXML?

« on: February 22, 2019, 10:35:01 AM »

Hi,

Testing something on a 10.1.0.4 server with ERM installed..I have a bunch of application groups that I need to update, and ARS_SUPPORT_HOLD=1 set in ars.cfg..

Code: [Select]

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.
Here's my XML-

Code: [Select]

<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>
Another weird thing- when i export an application group that has ERM setup via the admin client, the enhancedRetManagement field is set to "false"

I have tried a variety of tweaks/changes to the XML, because I know how specific ARSXML is, but i am not having any luck. Has anyone encounterd thisthis?

268

iSeries / Re: script to update storage set

« on: February 20, 2019, 11:18:29 AM »

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

ARSXML is your friend here if you are going down the route of versioning the old app groups and adding new. you could export all your app groups as a batch, and then edit each storage set to your needs.

269

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

« on: February 19, 2019, 07:04:06 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/.....

270

MP Server / Re: Error running ARSXML export.

« on: February 16, 2019, 11:43:00 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

I tried this yesterday. I exported one of the heaviest used AG's from our system, and tried exporting it directly to 10.1 with a newly created storage set. It looks like everything worked, except there is the one field depricated and ARSXML doesnt like it, it's logDBqueries or something. So I'm going to have to tinker with that a bit. I was going to change that logging anyway.