Re: Storing source as DDL instead of DDS

SCM is a good thought. Back in the day you could do a DSPPGM and see the
date the underlying source was last modified
Source file . . . . . . . . . . . . . . . . . . : QPGMSRC
Library . . . . . . . . . . . . . . . . . . . : ROB
Source member . . . . . . . . . . . . . . . . . : ATROY2
Source file change date/time . . . . . . . . . . : 05/30/06 11:39:14

And match that against DSPFD of the source physical file.
Last source update date/time . . . . . . : 05/30/06 11:39:14

But there's nothing like this for file descriptions. Some change
management systems could tell you if a file was changed "outside of the
system" and ask you what you wanted to do. For example, we used to have a
real issue with people changing printer file definitions to go to specific
printers. They could tell us this. Even if the printer file was on an
endpoint system.
There's nothing in any source to say "if I generate this my record format
level ID would be..." or any such thing. And is even record format level
id good enough? Does it catch check constraints? Do you want it to? For
example if I do a
ADDPFCST FILE(MYLIB/MYFILE) TYPE(*CHKCST) CHKCST('RECID IN(''A'', ''Z'')')
Do you really want to recompile all your programs using RLA just to get
past the record format level check? Now it wouldn't make you do that.
That doesn't affect record format level id.
But, still, wouldn't you want your change management to include that the
next time you regen the file?


Rob Berendt