db2 SQL2036N and SQL1652N

When performing the db2move load -lo replace to continue the “restore” from my previous post, I failed once more, this time with first SQLSTATE SQL2036N, “The path for the file or device path/device is not valid.”, and later (after chmod o+x on the directory), SQLSTATE SQL1652N, “File I/O error occurred”.

Why does IBM write this kind of misleading error messages? What’s wrong with a simple ENOPERM, ENOENT, “Permission Denied”, or “No such file or directory” message?

I am logged in as user ‘root‘, but the db2move command simply seem to tell another DB2 process to load the import files, and this is probably a privilege separated process that can’t open the directory containing my *.ixf files.

So, chmod o+x on the directory to the rescue! (Solved the SQL2036N) – Only to have it fail with another error when it is the actual files that cannot be opened by the unprivileged user.

chmod o+r on the files to the rescue, then! 🙂 (Solved the SQL1652N).

Yes, both these error messages were due to the fact that the files were not readable by anyone but root. Hope this helps someone! (Feel free to investigate the advertisements if you find any of my tips useful!) Nudge, nudge, know what I mean, know what I mean? 🙂

db2 SQLSTATE 57019 because of BACKUP PENDING

I created a new db2 database, updated LOGARCHMETH1, LOGFILSIZ and some other things, then tried to import data created with db2move and db2look with a command like this:

db2 -tvf filename.dat

It failed, with SQLSTATE=57019, because of BACKUP PENDING.

I didn’t feel like performing a backup on an empty database, so I did this to solve the problem:

db2dart databasename /CHST /WHAT DBBP off

where “databasename” was obviously the name of my database. This successfully changed the state of the DB Backup Pending flag to “off”, which allowed me to do my import! Yay!