ALIAS limitation in DDS (was: TIMESTAMP(0) in DDS)

[Joe Pluta <joepluta@xxxxxxxxxxxxxxxxx>]

And now for another reason to not use DDS (as if there weren't enough 
already): there is a limitation, undocumented as far as I know, of 30 
characters for the length of an ALIAS in DDS.  So while you can have 
long field names in your DDS files, you can't have REALLLLLLLY long 
names.  :)

On 4/28/2021 1:38 PM, Joe Pluta wrote:
> No, not to save bytes, Rob.  Just because most of our files use DDS, 
> and I was very close to having it work so that I could copy from an 
> SQL created table to the DDS generated one using CPYF.  So now I've 
> got two ways to go: create DDS with full timestamp and use SELECT INTO 
> or go DDL.  Either way is fine.
>
> On 4/28/2021 1:05 PM, Rob Berendt wrote:
> > If you are doing this solely to save bytes then do NOT do what 
> > Birgitta said as you will be wasting additional space.
> > Again, even though DSPPFM shows a timestamp(0) column taking several 
> > bytes and looking like '2021-04-28-13.59.00' it really only takes 7 
> > bytes internally.  So, storing it as a character would use 18 bytes.  
> > Even if you drop all the separators you'd still be consuming 14 bytes 
> > versus the 7 bytes of an internal representation of a timestamp(0) 
> > column.
> >
> > I'd like to know by what mathematical gymnastics they get a 
> > timestamp(0) column to take 7 bytes as I suspect that some of you 
> > will not believe IBM's documentation until you understand that.
> >
> > Rob Berendt