Re: Can I use DDS to create an SQL table name

On 24-Oct-2014 10:38 -0500, Darryl Freinkel wrote:

If you use iNav, you can convert all DDS to DDL. That would help
you modernise quickly and take advantage of the bigger buffer sizes
which gives better performance.

Of course, "bigger" is not always better, with regard to the performance of every [type of] application and\or system [environment]. To be clear, "bigger buffer sizes" could just as well give worse performance; the likelihood increases that the performance effects could be worse, if the applications using the changed file(s) had not previously or simultaneously been changed from RLA to SQL DML.

I will take this opportunity _to remind_ that conversion from DDS to DDL is *not* in any way "modernizing" the database. A change that is not required, is merely change [for the sake of change]; such changes effected without requirements are likely to expose unforeseen issues. If there is a feature without support via the DDS, and that feature is available only with the SQL DDL, then a change specifically to implement that feature via DDL would qualify as a valid modernization; e.g. implementing _surrogate keys_ using IDENTITY columns, for which no support exists in\via DDS.

There are no special "bigger buffer sizes" that result from a mere conversion; the Page Size setting defaults are different between DDS and DDL, but they can be customized. There is little that comes from that conversion that could not have been achieved by a change to [the creation of] the existing DDS-defined files. The one conspicuous difference from that change, is the potential for read-performance improvements for the lack of data validation performed on read [per the assumption that all SQL data was validated on input\write] is one _non-modernization_ benefit from the change; for that same effect, there is an implicit potential for an existing dependence on the non-validation effect to be exposed in applications that use a file that was changed.

Changing from DDS to SQL DDL is best performed only *after* having converted existing applications from using RLA to using SQL DML, to prevent some difficulties that might be encountered with existing and\or persisting non-SQL applications from having changed the underlying database physical *FILE objects into database SQL TABLE *FILE objects; most notably, Record Format Level Identifiers and Data Mapping Errors per increased validation requirements for SQL database objects. Failing to consider the[se and possibly other] side effects of changing from DDS to SQL DDL can result in issues that were not foreseen or noticed in testing. I know of some installations that had implemented such a switch, only to find out afterward that negative effects on some existing applications required that they back-out the changes... surely at great cost; I recall several specifically, one because an APAR was opened, regardless there was nothing that would be /fixed/ because they were closed Permanent Restriction (PRS) [increased memory footprint for journaling had caused performance problems due to implicit Page Size (PAGESIZE) change; since, the SQL was enabled to set a smaller page size to reduce the memory footprint for the non-SQL accesses] and all but one of the others were incidents of data mapping errors being effected on input\write that had never been diagnosed before the change to DDL.