On 10 Sep 2013 12:04, Needles,Stephen J wrote:
Our transition from DDS to DDL is to be accompanied by a
conversion to SQL I/O. This is to support business objects that
are represented via SQL Views as the Business representation of
the objects often utilizes columns from many tables. <<SNIP>>
The SQL is quite content to use DDS PF. Effectively the only concern
is that they be limited to one member; MAXMBRS(1). Again, no reason to
change to DDL, unless there is something specific that the change would
benefit your applications and\or data.
If not every access has changed to SQL DML before changing to SQL
DDL, then what I recall of possible concern...
Beware the possibility that code may have a dependence on writing bad
[decimal] data, but that will no longer be possible after changing the
files to SQL TABLE per use of SQL DDL. I have seen RLA code that makes
very *poor* assumptions about errors, such that decimal data errors that
are new to the application [per a change to use the SQL TABLE], rather
than being manifest to the user, are just ignored or sometimes even
presumed by the code to be, for example, a row-already-exists condition.
Now I would not recommend avoiding doing something based on an
assumption there are poorly coded applications, so the point is that the
errors that would never have occurred will suddenly be exposed. I
experienced several customers that made the change and suddenly were in
a position of urgently having to transition back to DDS PF because they
were unaware of the effects from having changed; i.e. they blindly
effected a change, a change for the sake of change, and each was forced
to repeal their decision when an unexpected nuance arose even after
their [apparently insufficiently encompassing] testing had passed with
success.
There is a potential that Record Format Level Identifiers will be
problematic. Because the SQL knows\cares nothing of the RcdFmt LvlId,
having first changed all I\O to SQL ameliorates any differences. But if
not *everything* has changed, some code [or query definition; or similar
feature that stores the level identifier] might start failing with a
cpf4131 [or similar] level check error. Because not merely the user
applications may be impacted, i.e. some utilities [including CPYF and
restore] which depend on that level identifier to infer either
compatibility or incompatibility of the data buffer, even ensuring all
user-created code is changed to use SQL I\O may not be sufficient.
The algorithm for PAGESIZE is different for SQL INDEX than keyed DDS
LF. RLA can often operate better with smaller, but the SQL desires and
in most cases require larger page size than the CRTLF [and CRTPF]
default. With larger page sizes come larger memory requirements for
/paged/ data, so the characteristics of database paging changes, as well
come impacts to explicit or system-managed access path protection which
may need to be adjusted. Continued RLA would typically page much more
than is desired, thus impacting performance negatively, even while the
effects for performance on the SQL accesses would be positive.
midrange.com
