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

Pages: [1]
1
WEBI interface / Replacing OnDemand Fat Client with Web browser based GUI
« on: February 25, 2016, 02:00:24 PM »
    We've never used WEBi or Content Navigator.    We're in the process of upgrading a system to OnDemand 9.5 running on RedHat Linux 7.0.   The system has about a 1,000 users and we've been asked to build a web browser based GUI to replace the OnDemand 9.5 fat client for almost all the users.    Should we build our own browser based GUI connecting to ODWEK Java APIs or would Content Navigator be a good fit to completely replace the OnDemand 9.5 fat client for most users?  All the users would just be viewing data stored in Content Manager for OnDemand without any update access.   They would be viewing mostly line data documents, but there are some AFP documents.   If Content Navigator is a good fit for this purpose, does anyone know of any good documentation specific to using Content Navigator as a replacement for the OnDemand fat client?
    We have a home grown Java application that connects to another OnDemand 9.5 system through ODWEK Java APIs to get a small subset of data.   That system uses AFP2PDF to convert our AFP documents to PDFs for display on the client PC.

Thank You,
Brian Blunt

2
MP Server / Re: arsdb -u doesn't work on new install of DB2 10.1 & OD 9.0.0.2
« on: August 15, 2013, 12:55:37 PM »
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.                                                           

3
MP Server / Re: arsdb -u doesn't work on new install of DB2 10.1 & OD 9.0.0.2
« on: August 15, 2013, 06:34:21 AM »
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
 

4
MP Server / Re: arsdb -u doesn't work on new install of DB2 10.1 & OD 9.0.0.2
« on: August 13, 2013, 11:51:41 AM »
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

5
MP Server / arsdb -u doesn't work on new install of DB2 10.1 & OD 9.0.0.2
« on: August 09, 2013, 01:23:24 PM »
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

6
MP Server / Re: How do I migrate CMOD 7.1.2.8 on AIX to CMOD 8.5.0.7 on Linux?
« on: July 30, 2013, 08:22:21 AM »
Alessandro,
     Thank you very much for all the information.     Unfortunately, I don't think we know enough about DB2 or OnDemand to try the more daring approach.   We'll try the slowest and safest.   If that proves to be too slow, we might come back for a more daring approach.

Thanks,
Brian

7
MP Server / How do I migrate CMOD 7.1.2.8 on AIX to CMOD 8.5.0.7 on Linux?
« on: July 17, 2013, 11:17:33 AM »
Current System:
AIX 5.3
CMOD 7.1.2.8
DB2 8.2
TSM: 5.3

New System:
RedHat Linux 5.9
CMOD 8.5 or 9.0
DB2 9.7
no TSM(cache only)

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

Questions:
Is CMOD designed to allow us to run an ARSDOC GET on CMOD 7.1.2.8 and run ARSLOAD on a CMOD  8.5.0.x system to correctly load the data pulled from the 7.1.2.8 system?

Is CMOD designed to allow us to run an ARSDOC GET on CMOD 7.1.2.8 and run ARSLOAD on CMOD 9.0.x system to correctly load the data pulled from the 7.1.2.8 system?

If this ARSDOC GET/ARSLOAD procedure should work for either version, should we move to CMOD 8.5 or CMOD 9.0?

If we use batch ARSDOC GET(old CMOD) and ARSLOAD(new CMOD) procedures, how can we ensure documents loaded into the new CMOD age off on the correct dates?    Basically, we?ll be getting 6, 5, 4, 3, 2, 1, etc... year old documents from the old system and we want the new system to recognize them as 6, 5, 4, 3, 2, 1, etc... year old documents when they?re loaded.

Pages: [1]