Ok, so if you want to limp along with layouts like (exaggerated)
...
SIZE DEC(3,0) If all 9's use SIZE1
...
SIZE1 DEC(5,0) If all 9's use SIZE2
...
SIZE2 DEC(7,0) If all 9's use SIZE3
...
SIZE3 DEC(9,0)
You can by specifying not to check for record format level identifiers (or
by using sql instead), and just ignoring trailing new fields. I
understand how some people would be happy with returning invalid data,
like the size of an object is 999 when it's higher than that, versus
having their program error out.
And I do use DSPOBJD for quick and dirties. But for anything imbedded I
prefer APIs.
And I am not the only one who would like a change. Even if you'd be
satisfied with an additional date field instead of fixing the other date
field you still need to submit a DCR. Again, yes, you could get around it
by calling functions, like idate, to resolve it, but you can't build an
index over a function (can you?). This can get into performance issues.
https://www-912.ibm.com/r_dir/ReqDesChange.nsf/Request_for_Design_Change?OpenForm
For the James Lampert's out there (and other long time users) did the
outfile for DSPOBJD always have ODDCEN, ODCCEN and other century flags?
Anyone have a V1R1 manual (or whenever DSPOBJD came out)? I see that the
list objects api came out in V1R3. I've been on the machine since V1R2
and I can't remember and those manuals have long been disposed of.
Rob Berendt
midrange.com
