Chuck,
Thank you for your input.
As this transition to SQL DML/DDL will take time, the points concerning the writing of "bad" data are most probable. I will do my best to plan for them.
I hear ya on the LvlID.
We have a pretty good amount of memory and disk and are not too concerned at this point about PAGESIZE, but will have to be as we continue our trek. Is there a source to quantify the PAGESIZE differences for planning purposes?
Steve Needles
-----Original Message-----
From: midrange-l-bounces@xxxxxxxxxxxx [mailto:midrange-l-bounces@xxxxxxxxxxxx] On Behalf Of CRPence
Sent: Tuesday, September 10, 2013 2:54 PM
To: midrange-l@xxxxxxxxxxxx
Subject: Re: REUSEDLT(*NO) vs. REUSEDLT(*YES)
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.
--
Regards, Chuck
--
This is the Midrange Systems Technical Discussion (MIDRANGE-L) mailing list To post a message email: MIDRANGE-L@xxxxxxxxxxxx To subscribe, unsubscribe, or change list options,
visit:
http://lists.midrange.com/mailman/listinfo/midrange-l
or email: MIDRANGE-L-request@xxxxxxxxxxxx Before posting, please take a moment to review the archives at
http://archive.midrange.com/midrange-l.
________________________________
This communication, including attachments, is confidential, may be subject to legal privileges, and is intended for the sole use of the addressee. Any use, duplication, disclosure or dissemination of this communication, other than by the addressee, is prohibited. If you have received this communication in error, please notify the sender immediately and delete or destroy this communication and all copies.
TRVDiscDefault::1201
midrange.com
