Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

DB2 on z/OS support #638

Closed
Muni10 opened this issue Nov 4, 2013 · 9 comments
Closed

DB2 on z/OS support #638

Muni10 opened this issue Nov 4, 2013 · 9 comments

Comments

@Muni10
Copy link
Contributor

Muni10 commented Nov 4, 2013

Background: We are using flyway for several Oracle based systems and are now starting a new migration for an existing application. We therefore want to use flyway for database migrations there as well.

However, when running the migrations, Flyway is looking up the SYSCAT schema in the DB2 database. This schema does not exist on z/OS. We get the following error message:
DB2 SQL error: SQLCODE: -204, SQLSTATE: 42704, SQLERRMC: SYSCAT.SCHEMATA

Could you investigate this issue?

@axelfontaine
Copy link
Contributor

Thanks for your report.

Unfortunately I don't have access to a z/OS environment.

I you wish to add support for DB2 on z/OS and maintain the code, I would gladly accept a pull request.

Cheers
Axel

@cteig
Copy link
Contributor

cteig commented Dec 15, 2013

Hi

I've made the necessary changes to flyway so it is possible to use flyway on zOS. But our db2adm has asked me to change the tablename and columnname in the metatable (schema_version) from lowercase to uppercase.

I see in the code that for all other databases, lowercase are used for scema_version-table. What are the reasons for this? I have almost ready a pull request, but want to know what you think about that flyway for db2 on zOS uses uppercase instead of lowercase like the rest.

Cheers
Christine Teig

@axelfontaine
Copy link
Contributor

Hi Christine,

the table name (and its case) is configurable through the flyway.table property. As for the columns yes, they are currently fixed to lower case. This is how things work and it's not really a priority for me to make this configurable, as this really is a private table for Flyway nobody else should mess with or depend on in any way.

Cheers
Axel

axelfontaine pushed a commit that referenced this issue Aug 1, 2014
@Galanodel
Copy link

Hi,

I m still facing the same problem in Flyway version 3.2.1.
[ERROR] Failed to execute goal org.flywaydb:flyway-maven-plugin:3.2.1:migrate (default-cli) on project db-migration: org.flywaydb.core.api.FlywayException: Unable to check whether schema "TCBS72IBKT" exists: [SQL0204] SCHEMATA in SYSCAT type *FILE not found.

As it is reported to have been solved in version 3.1 (http://flywaydb.org/blog/flyway-3.1.html), maybe there is another reason that I m still getting this error?

Thank you!

@axelfontaine
Copy link
Contributor

@cteig Thoughts?

@cteig
Copy link
Contributor

cteig commented May 7, 2015

Hi @Galanodel

Do you know the DatabaseMetaData.getDatabaseProductVersion ?
The Flyway code use the DatabaseProductVersion to identify the data server to which an application is connected.

If it helps, you can use my little test-project to get it. https://github.com/cteig/databaseProductVersion. Just update to your version of db-driver in the pom dependency and your database url, user and password. Or if you use a database client i.e squirrel, maybe you can find DatabaseProductVersion there.

Christine

@Galanodel
Copy link

Hi Christine ( @cteig )

thank you.
I extracted getDatabaseProductVersion from squirrel, it is: 06.01.0000 V6R1m0. We are using a 9.11 driver version to connect from our application, squirrel, etc ... successfully.

Another thing though that I noticed in your example project (databaseProductVersion) is that you use the db2jcc (com.ibm.db2). I am using db2 for AS/400 (jt400).
So, I take it this is fixed for another database then?

Thanks a lot again!

@cteig
Copy link
Contributor

cteig commented May 8, 2015

Hi
Yes I think you are right. For DB2 z/OS, getDatabaseProduct will return a string who starts with "DSN". The pull request is only tested agains DB2 z/OS.
But, I see it will be usefull to change the check who identify the data server, so it give a better feedback. I will look at it.

Christine

@Galanodel
Copy link

Hi Christine,

thanks a lot for your time and effort! I wait eagerly for your news!

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Development

No branches or pull requests

4 participants