Perhaps you have to make two runs of dbunload: dbunload -n for all the schema but no data, then dbunload -d -e table-name for just the data for all the tables except table-name.

Caveat Emptor: I did not test the suggestion above, but I do remember that dbunload -e was [cough] disappointing the first and only time I tried it... after which I thought that "-e" meant "eliminate most basic functionality".

IMO the creators of dbunload worry just a little bit too much about people making mistakes using it... the Help is full of exhortations similar to "Do not attempt to dry wet newspapers in this microwave oven"... these exhortations do not appear elsewhere in the Help, say, in the section on DROP TABLE.

When these nanny exhortations translate into actual limitations is where I go ballistic. Some safety limitations make sense, like disabling the nailgun trigger until the snout is pressed against the surface. Even those, however, come with unintended consequences... like bounce nailing which can be, um, exciting when done clumsily. And that's the real world, this is SQL: no human being has ever been killed or injured by dbunload. It's the limitations that cause problems, not the functionality.

Personally, I would like something like dbunload -ed table-name: That would do a full-tilt everything-included dbunload EXCEPT that it would not actually unload the data for table-name. Databases frequently contain things like DBA.big_stupid_trace_table which grow like weeds, filled up with data that is of no interest a day later, and certainly isn't needed when moving the database somewhere else.

And that's only reason I've ever wanted to use -e, which might explain why I've never used it successfully... maybe I should try my own suggestion :)

Gosh... what I'd really like is a dbunload API... better yet, some simple SQL-like command set to tell dbunload what I want it to do. But not like that Microsoft ETL crap that runs on a geological timescale as well as being hopelessly incomprehensible to use.