DDL source members Was: include current date in logical file

Well, there is iNav's "Generate SQL" option. If you do use STRSQL to
create an sql object you could use that to create the source. Then you
could store that as a stream file or as a source file member. iNav's run
sql script favors stream files. RUNSQLSTM will use either a stream file
or a source file member (at least at 7.1)
Source file . . . .
Library . . . . .
Source member . . .
Source stream file .

Given that, do you ever really need to store the source? After all you
can regen it. And, since someone may have used something to alter a
column, alter authority, add a column label, etc is your source really
accurate? Really, how often do you alter the security of a file using an
sql statement versus some other method? Therefore what are the odds that
someone stored the updated authority source in your sql statement source?

To generate a test library with 500 tables, 2000 indexes, several hundred
views, a plethora of constraints (referential and otherwise) are you
really going to run all those source members or are you going to save the
library and restore it to a different name?

Ok, so the table didn't get backed up because of a lock. And then it got
deleted. And you despise built in tools in the OS because they work and
are too easy to use so you refuse to journal something. Now you're hoping
that it wasn't deleted because someone figured the whole library was old
and blast it, and decided the source directory was old and blast that too.

I can recall one time when I wish I had the source. It was a table that
got corrupted. I only used it to test new releases of the OS. I didn't
know it was corrupted. By the time I needed it again it was only on media
in corrupted format. I could not run the api to generate sql source
against it because of the corruption. I had to redo it from scratch.

In summary, you can try retaining SQL source but don't expect it to be
current.

Rob Berendt