arsdb -u doesn't work on new install of DB2 10.1 & OD 9.0.0.2

[bblunt]

I've tried running the arsdb -u command from the new system as archive(DB owner) and as root, but I get the same result either way.   I see all the warnings about not running arsdb -c until I run arsdb -u and set my ARS_ORIGINAL_CODEPAGE, but I just can't get the arsdb -u command to work.   Any ideas why this doesn't work?

[attctodv1:archive]# db2ilist
archive

[attctodv1:archive]# ./arsdb -u -I archive
arsdb:  ARS4012E Unable to initialize environment. The return code is 1

[root@attctodv1]# db2ilist
archive
[root@attctodv1]# ./arsdb -u -I archive
arsdb:  ARS4012E Unable to initialize environment. The return code is 1

New System:
RedHat Linux 5.9
CMOD 9.0.0.2
DB2 10.1
no TSM(cache only)

New System Configuration:
[root@attctodv1 config]# more ars.ini
[@SRV@_ARCHIVE]
HOST=
PROTOCOL=2
PORT=0
SRVR_INSTANCE=ARCHIVE
SRVR_INSTANCE_OWNER=root
SRVR_OD_CFG=/opt/ibm/ondemand/V9.0/config/ars.cfg
SRVR_DB_CFG=/opt/ibm/ondemand/V9.0/config/ars.dbfs
SRVR_SM_CFG=/opt/ibm/ondemand/V9.0/config/ars.cache

[@SRV@_DD]
PROTOCOL=1

[root@attctodv1 config]# egrep '^ARS|^DB2' ars.cfg
ARS_NUM_LICENSE=165
ARS_LANGUAGE=ENU
ARS_SRVR=
ARS_LOCAL_SRVR=
ARS_NUM_DBSRVR=4
ARS_TMP=/tmp
ARS_PRINT_PATH=/tmp
ARS_DB_ENGINE=DB2
ARS_DB_IMPORT=0
ARS_DB_PARTITION=
DB2INSTANCE=archive
ARS_DB2_DATABASE_PATH=/arsdb
ARS_DB2_PRIMARY_LOGPATH=/arsdb_primarylog
ARS_DB2_ARCHIVE_LOGPATH=/arsdb_archivelog
ARS_DB2_LOGFILE_SIZE=1000
ARS_DB2_LOG_NUMBER=40
ARS_DB2_TSM_CONFIG=/opt/tivoli/tsm/client/api/bin/dsm.opt.db2
ARS_ORACLE_HOME=/oracle
ARS_STORAGE_MANAGER=TSM
ARS_MESSAGE_OF_THE_DAY=
ARS_TRACE_SETTINGS=
ARS_LDAP_SERVER=
ARS_LDAP_PORT=
ARS_LDAP_BASE_DN=
ARS_LDAP_BIND_DN=
ARS_LDAP_BIND_DN_PWD=
ARS_LDAP_BIND_ATTRIBUTE=
ARS_LDAP_MAPPED_ATTRIBUTE=
ARS_LDAP_ALLOW_ANONYMOUS=

I ran db2sampl to create the sample DB and looked at it's Data Base CODEPAGE information.   Should I use 1208 as my ARS_ORIGINAL _CODEPAGE?

db2 => get database configuration for sample show detail

       Database Configuration for Database sample

 Description                                   Parameter   Current Value              Delayed Value
 ---------------------------------------------------------------------------------------------------------------
 Database configuration release level                    = 0x0f00
 Database release level                                  = 0x0f00

 Database territory                                      = US
 Database code page                                      = 1208
 Database code set                                       = UTF-8
 Database country/region code                            = 1

Plan:
1) Load new CMOD & DB2 on RedHat Linux server
2) Use ARSXML to export administrative objects from old CMOD 7.1.2.8 on AIX
3) Modify ARSXML output slightly to acchieve desired changes on new system
4) Use ARSXML to load administrative object on new CMOD on Linux
5) Create a batch process of ARSDOC GET commands to pull data from the existing OnDemand 7.1.2.8 install on the AIX system.
6) Create a batch process of ARSLOAD commands to load data from the existing OnDemand 7.1.2.8 install on the AIX system to the new OnDemand on the Linux system.
7) Repeat steps 6 & 7 until all data has been moved to new CMOD on Linux server

[kbsiva]

Well let me ask the obvious are all your configs/directory paths valid ,right permission etc? did not see a port/host values in the ini file may be you had  just left it out for forum . Just a suggestion try to enable the trace and see what's happening when you run the command.

Regards,
Siva

[bblunt]

I made the changes below to try to add tracing and ran arsdb -u again, but didn't get a trace file.     Normally, I'd restart OnDemand to get the tracing to work, but I can't start OnDemand until I get this ARS_ORIGINAL_CODEPAGE figured out.    I double checked all the file access settings to make sure root has the access it needs to all the files and I didn't find any problems.    I tried setting  HOST=attctodv1, instead of just letting it assume it should check the local system, but that didn't seem to make a difference.   I also tried explicity entering PORT=1445, instead of letting it pick the default port 1445, but that didn't seem to make any difference.    I'm guessing it's something simple, because I've never setup a new OnDemand system. 

[root@attctodv1 config]# grep TRACE ars.cfg
ARS_TRACE_SETTINGS=/opt/ibm/ondemand/V9.0/config/trace.settings

[root@attctodv1 config]# grep TRACE_ trace.settings
TRACE_FILE=ARCHIVE.trace.log
TRACE_LEVELS=ALL=15

[Alessandro Perucchi]

Hello bblunt,

Well from what I see, can you run db2 commands as root?

I mean, can you do simply a "db2"

If not (and I don't mean adding the db2 binary in PATH), I mean to source the file as root.

~archive/sqllib/db2profile

->    . ~archive/sqllib/db2profile

Then you can run some db2 commands... like "db2 connect to archive" as root.
And then normally your commands arsdb should work as expected.

One question... really important question... Why on earth do you want to use "root"? I know the documentation of CMOD specify the user "root" everywhere... but from a security point of view this is really BAD.
I would suggest that after you make it work with user "root", to redo the exercise with a specific user...

Sincerely yours,
Alessandro

[Alessandro Perucchi]

Another point.... before I forget...

the option in ars.cfg

ARS_TRACE_SETTINGS=

works ONLY when the CMOD server is started (arssockd / arsobjd). And not with other commands.

Sincerely yours,
Alessandro

[bblunt]

Alessandro,
    Thank you for the responses.   I definitely agree with your opinion on root and I plan to switch to a different ID for CMOD after I get it working with root.    I run . /home/archive/sqllib/db2profile from root, before attempting any CMOD commands.   I can run DB2 commands from root, but I'm not sure if I have everything setup that I should for archive.   As you can see the db2ilist command below shows the archive instance.   However, the "db2 connect to archive" doesn't work, because the archive DB hasn't been created.   Since I haven't run arsdb -c, I think that's correct, but I'm not 100% certain.   Also, I've been able to run db2sampl to create the sample DB and remove it.  I've tried the arsdb -u with and without the sample DB being loaded.   I've also tried upper and lower case SRVR_INSTANCE=archive & SRVR_INSTANCE=ARCHIVE to see if that would make a difference.
   
[root@attctodv1 bin]# db2ilist
archive

[root@attctodv1 bin]# db2 connect to archive
SQL1013N  The database alias name or database name "ARCHIVE" could not be
found.  SQLSTATE=42705

[root@attctodv1 bin]# db2 connect to sample

   Database Connection Information

 Database server        = DB2/LINUXX8664 10.1.2
 SQL authorization ID   = ROOT
 Local database alias   = SAMPLE

Since, I'm not planning to upgrade directly from CMOD 7.1.2.8, but arsdoc get the data from the old CMOD and arsload the data into the new CMOD, I think I should be able to just take the default value for ARS_ORIGINAL_CODEPAGE.   I just don't know what that default value is for a new CMOD 9.0 with DB2 10.1 on RedHat 5.9.   When I ran db2sampl to create the sample DB2 and looked at the DB config information, I could see codepage = 1208.   I just don't know enough about DB2 or CMOD to know if that's my default value for my configuration or not. 

[root@attctodv1 config]# db2 get db cfg for sample |more

       Database Configuration for Database sample

 Database configuration release level                    = 0x0f00
 Database release level                                  = 0x0f00

 Database territory                                      = US
 Database code page                                      = 1208
 Database code set                                       = UTF-8
 Database country/region code                            = 1

Thank You, Brian Blunt
 

[bblunt]

I've been talking to IBM support.   I still haven't been able to run arsdb -u and get a response, but they gave me some information about ARS_ORIGINAL_CODEPAGE values.   So, I set ARS_ORIGINAL_CODEPAGE=1208 and ran arsdb -gcv to create the DB.    We'll see how our arsdoc get & arsload data migration goes.

Information from IBM support:
I discussed this with my Team Lead and this is what he says:           
                                                                       
If you are running an CMOD 8.4.1 English DB2 database on AIX, then when
you upgrade to V9 you need to set: ARS_ORIGINAL_CODEPAGE=923           
                                                                       
                                                                       
If you are running an CMOD 8.4.1 English DB2 database on AIX, then when
you upgrade to V9 you need to set: ARS_ORIGINAL_CODEPAGE=923           
                                                                       
If you create a brand new instance of CMOD on V8.5 or V9, when CMOD     
creates the database it will use a unicode (1208) code page.  So       
ARS_ORIGINAL_CODEPAGE=0  or  ARS_ORIGINAL_CODEPAGE=1208 needs to be set.
This is because CMOD does not need to translate its unicode to the local
db codepage.                                                           

[Alessandro Perucchi]

Hello bblunt,

am I understanding correctly, if you add the ARS_ORIGINAL_CODEPAGE, it works?

Strange, because all the time I've seen something like that, you should receive an error message saying that you need to add it... Not simply an error message.

I have seen with DB2 10.1 this kind of problem http://www-01.ibm.com/support/docview.wss?uid=swg21620763.
But apparently that doesn't fit your error message...


I am rereading your question and your plan...
I have found a mistake in your configuration file (ars.cfg)

ARS_STORAGE_MANAGER=TSM

and you said, that you want to use cache and no TSM, so it means that the value must be:

ARS_STORAGE_MANAGER=CACHE_ONLY

But this won't help you with your arsdb problem... but will help later on!

Wenn you want to show the ars.cfg, don't use "egrep '^ARS|^DB2' ars.cfg" otherwise you'll miss lots of parameters... it is better to use something like

Code: [Select]

egrep -v '^#|^$' ars.cfg
Then you are sure everything will be inside.


Now, I see that everything seems ok from DB2 point of view, you can connect, you can see who is the instance owner... the config files (even if I see only part of it due to your wrong egrep) seems to be ok...
Have you created the following FS/directory?

• /arsdb
• /arsdb_primarylog
• /arsdb_archivelog

and if yes, what are the permissions? (user/group/acl)

You can activate the debug mode of arsdb (not documented... but it works :-D) with that command

Code: [Select]

arsdb -u -I ARCHIVE -v -1 /tmp/mylog.log -2 ALL=15
I always put the -v when I run a command, so I have a more verbose message.

The undocumented but working option are

• -1
• -2

And the first needs the log file, and the second you need to say what kind of trace level you want... with ALL=15 you get everything...

Then to read the log, you need to use the arstfmt command (arstfmt -i mylog.log)


Hope that helps a bit further...

Sincerely yours,
Alessandro