Dear Colleagues,
this is the first time I'm using the enablement for an Oracle based job to be moved into Linux - DB2 platform.
I got errors here reported at point 5, and another at point 6; in points 1-to-4 I describe precisely the performed steps to set up my environment.
I appreciate any comment and support to solve the issues.

$ db2stop
SQL1064N DB2STOP processing was successful.
$ db2start
SQL8007W There are "87" day(s) left in the evaluation period for the product "DB2 Connect Server". For evaluation license terms and conditions, refer to the License Agreement document located in the license directory in the
installation path of this product. If you have licensed this product, ensure the license key is properly registered. You can register the license via the License Center or db2licm command line utility. The license key can be
obtained from your licensed product CD.
SQL1063N DB2START processing was successful.

Re: Neither create table nor tablespace: is it a setup problem ?

‏2012-03-15T21:25:15Z

This is the accepted answer.
This is the accepted answer.

CREATE TABLESPACE syntax is quite different in DB2 from what you might expect in Oracle, due to the differences in physical layout of data. To simplify things you can omit all those physical parameters because automatic storage management is enabled by default in DB2. Note that there are two types of temporary tablespaces in DB2: "user" - for temporary tables you create, and "system" - for DB2 internal use. One system temporary tablespace is created by default.

Re: Neither create table nor tablespace: is it a setup problem ?

CREATE TABLESPACE syntax is quite different in DB2 from what you might expect in Oracle, due to the differences in physical layout of data. To simplify things you can omit all those physical parameters because automatic storage management is enabled by default in DB2. Note that there are two types of temporary tablespaces in DB2: "user" - for temporary tables you create, and "system" - for DB2 internal use. One system temporary tablespace is created by default.

Thanks Ivanov1, I get the point and now I'll try to map the options inside the create tablespace statement of the customer into the implicit or explicit DB2
corresponding features.
This applies to
LOGGING, DATAFILE, SIZE, REUSE, AUTOEXTEND ON, NEXT
and MAXSIZE UNLIMITED, EXTENT MANAGEMENT LOCAL, SEGMENT SPACE MANAGEMENT AUTO.
Anyway, by means of your suggestion the step of create tablespace is done. Inside operations management I'll complete the migration of the statement.

And now, have you any comment about the create table issue ? I have a lot (more tens) statements very similar to the following ones:
CREATE TABLE PCSCLASSBOM
(
CLASSBOMID NUMBER(20) NOT NULL,
CLASSID NUMBER(20) NOT NULL,
CHILDID NUMBER(20) NOT NULL,
CREATEDATA DATE,
LASTUPDATEDATA DATE
)
LOGGING
NOCOMPRESS
NOCACHE
NOPARALLEL
MONITORING;

It appears that LOGGING is a not accepted / recognized clause.
Thanks, c.l.

Re: Neither create table nor tablespace: is it a setup problem ?

Thanks Ivanov1, I get the point and now I'll try to map the options inside the create tablespace statement of the customer into the implicit or explicit DB2
corresponding features.
This applies to
LOGGING, DATAFILE, SIZE, REUSE, AUTOEXTEND ON, NEXT
and MAXSIZE UNLIMITED, EXTENT MANAGEMENT LOCAL, SEGMENT SPACE MANAGEMENT AUTO.
Anyway, by means of your suggestion the step of create tablespace is done. Inside operations management I'll complete the migration of the statement.

And now, have you any comment about the create table issue ? I have a lot (more tens) statements very similar to the following ones:
CREATE TABLE PCSCLASSBOM
(
CLASSBOMID NUMBER(20) NOT NULL,
CLASSID NUMBER(20) NOT NULL,
CHILDID NUMBER(20) NOT NULL,
CREATEDATA DATE,
LASTUPDATEDATA DATE
)
LOGGING
NOCOMPRESS
NOCACHE
NOPARALLEL
MONITORING;

It appears that LOGGING is a not accepted / recognized clause.
Thanks, c.l.

It's the same story again - Oracle-specific clauses to the table DDL statements are not supported because they don't make sense in DB2, due to the physical differences. If you use IDMT for migration, it will automatically strip the unnecessary clauses, otherwise you'll need to edit (remove) them manually.

It might also be a good idea to check the DB2 manuals for the correct statement syntax: http://publib.boulder.ibm.com/infocenter/db2luw/v9r7/index.jsp

Re: Neither create table nor tablespace: is it a setup problem ?

It's the same story again - Oracle-specific clauses to the table DDL statements are not supported because they don't make sense in DB2, due to the physical differences. If you use IDMT for migration, it will automatically strip the unnecessary clauses, otherwise you'll need to edit (remove) them manually.

It might also be a good idea to check the DB2 manuals for the correct statement syntax: http://publib.boulder.ibm.com/infocenter/db2luw/v9r7/index.jsp

Thanks again nivanov1 for your answer.
My assumption was that we can execute every Oracle plsql statement inside clpplus, therefore also those that generate the schema of my customer. Now I know that it is not true, some statements totally lawful in Oracle, are not executed as is in DB2 and discarded by clpplus. Really I expected something like that, expecially and only for very complex statements.
My initial approach after having suspended the migration and being started the application enablement was based on executing the scripts that generate the production schema in Oracle by means of the clpplus feature to execute plsql scripts. Probably my expectation was to obtain a coverage degree or a similar indicator for each plsql statement.
But now I have to change the approach. If I correctly understand, I need to connect immediately to the Oracle production environment with the IDMT in order to generate the equivalent set of scripts that allows to build the first DB2 migrated server. In such a way, how can we identify the Oracle statements partially covered by the DB2 ?
Anyway, let's go to apply IDMT.
c.l.

Re: Neither create table nor tablespace: is it a setup problem ?

Thanks again nivanov1 for your answer.
My assumption was that we can execute every Oracle plsql statement inside clpplus, therefore also those that generate the schema of my customer. Now I know that it is not true, some statements totally lawful in Oracle, are not executed as is in DB2 and discarded by clpplus. Really I expected something like that, expecially and only for very complex statements.
My initial approach after having suspended the migration and being started the application enablement was based on executing the scripts that generate the production schema in Oracle by means of the clpplus feature to execute plsql scripts. Probably my expectation was to obtain a coverage degree or a similar indicator for each plsql statement.
But now I have to change the approach. If I correctly understand, I need to connect immediately to the Oracle production environment with the IDMT in order to generate the equivalent set of scripts that allows to build the first DB2 migrated server. In such a way, how can we identify the Oracle statements partially covered by the DB2 ?
Anyway, let's go to apply IDMT.
c.l.