On 24-Oct-2014 12:18 -0500, Mike Cunningham wrote:
Chuck, what about access to the improved key indexing that an SQL
defined table gives you?
I am unsure what is alluded. Can a link be provided?
Given a SQL TABLE is a non-keyed database *FILE, and a keyed SQL
TABLE is a database *FILE with a PRIMARY KEY CONSTRAINT or UNIQUE KEY
CONSTRAINT, then the equivalent DDS PF is achieved with Add Physical
File Constraint (ADDPFCST). Effectively there is *no difference*
between the two files with regard to the keyed access path (ACCPTH); the
underlying support for /indexing/ [and enforcement] is identical, as
provided by the identical LIC DB methods betwixt, irrespective the
choice of those two means used to define the files and their keys.
An INDEX can be created on [a single-member] PF, and like the AccPth
of a constraint index, the keyed access path of the SQL INDEX is created
and treated identically [by the LIC database] no matter whether the
underlying physical data comes from either of a DDS PF or a SQL TABLE.
And then there is always the future to consider. My crystal ball
says at some point IBM will pull the plug completely on DDS for
database definitions just like it has pulled the plug on SEU. To
their credit, they have not gone the path of some other companies who
have said change your ways or don't upgrade, they have given us many
years to make the switch. So I don't see the demise of DDS anytime
soon but 5 years from now I'm not so sure.
And I suppose the future of /QDLS similarly shows support for *DOC
and *FLR going away.? Even if not, merely per having portended the
demise of the Data Description Specification support, I would expect
that crystal ball is due for maintenance or an upgrade to a newer model :-)
Until the system is reincarnated [much like the s/38 and s/36 were
reincarnated as the AS/400, and the respective legacy "environments"
provided], I very much doubt the DDS would be pulled; even if the
implication is only for the specifications capability for defining
database Logical File (LF) and Physical File (PF) [as if the compiler
might continue to enable processing DDS for DSPF and PRTF?]. The DDS is
effectively dead already however, with regard to database files, because
there was\is no intention to support [with DDS keywords\etc.] any new
SQL data-types and features. Even so, the DDS compiler continues to
function to create DBFs, and I would expect that compiler to continue to
function in perpetuity just like I would expect with the run-time of
OV/400, Query/400, DFU, and many other features. If the DDS compiler
had been an optionally-installed LPP, only then would I expect any
possible consideration for the removal of that compiler; too much code
[including some OS code] have dependencies on that OS feature.
Most who know me understand that I would never offer a guarantee, and
that I would be unlikely to bet, except on that which is all but
guaranteed. But on that specific matter, I must admit that I would be
quite willing to place a bet. I am confident the demise of the OS would
precede the demise of the ability to Create Physical File (CRTPF) or
Create Logical File (CRTLF) from DDS, and just as certain that the
demise of the OS would transpire as a direct result given an inability
to create database files from DDS; i.e. I expect few customers would be
willing or able to accept that effect, as a loss considered to be a
/bridge too far/, and I doubt the loss would be an impetus for a slew of
new customers to take their place.
midrange.com
