I see. Cost may far outweigh the benefit. Thanks for clarification Chuck.
Elvis
Celebrating 10-Years of SQL Performance Excellence
http://centerfieldtechnology.com/training.asp
-----Original Message-----
Subject: Re: DDS to SQL - date definition
SQL DML does not care about format level identifier. However as was
learned when a correction was made for TIMESTAMP, there are many people
using SQL TABLE for RLA [row level access]. Those non-SQL program file
open requests do care about the FmtLvlId; i.e. the LVLCHK [level check]
enabled file opens, will effect a CPF4131 when the identifiers do not match.
Although there is, IIRC, something with DATE data type in SQL that is
not possible to effect with DDS [dealing with NULL and default], I am
not sure if that difference is also part of the hash for the level
identifier. But the specific value causing a problem in the given
scenario, I am confident is the 'separator' attribute; noted in my prior
post.
FWiW:
Although it is easy to infer "just fix it" is intuitive, simple, or
not going to impact me, does not mean there are not many ramifications
-- even if only to somebody else. There will surely be pains no matter
how it is resolved [just like with TIMESTAMP; see my list of APARs in my
prior posting], because there are surely already many SQL TABLE with
DATE and TIME [just like there were with TIMESTAMP] that are already
being accessed using RLA. Consider CRTDUPOBJ, CPYF, RSTOBJ, ALTER [SQL
and CHGPF SRCFILE()], previous release, and ??? Existing applications
have just as much expectation to continue working as some new
/modernization/ activity. But fixes /with side effects/ will always be
problematic to some; they will have to deal with it -- and it might even
impact negatively, those requesting the change.
What is most confusing is given the 'least impact' change, which
allows restore and duplicate to maintain the Format LvlId for
compatibility, that when the _same_ file is created from source [or some
other effective copy] the level is expected to be the same, it would not
be the same after a PTF. There is just no way around the application
having to change, the restored file being recreated, or [not suggested]
the level checking ignored. Such confusion sometimes leads to more ire
than if the whole issue had been put to rest by "permanent restriction",
especially since impacts may only be noticed releases after the PTF.
Regards, Chuck
-- All comments provided "as is" with no warranties of any kind
whatsoever and may not represent positions, strategies, nor views of my
employer
Elvis Budimlic wrote:
Jeff, ask him if SQL DML even cares about formal level.
If it does not, there's really no excuse for not making DDL match DDS.
Elvis
midrange.com
