× The internal search function is temporarily non-functional. The current search engine is no longer viable and we are researching alternatives.
As a stop gap measure, we are using Google's custom search engine service.
If you know of an easy to use, open source, search engine ... please contact support@midrange.com.



Jon,

The "validation on read" does not mean in RPG or any other language, but
directly within the table.

Just try to copy invalid (packed) numeric data in a DDS described file with
CPYF *NOCHK. All records are inserted.
Create the same file/table with the same fileds/columns as the DDS described
file (you may use the GENERATE SQL-Statement in IBM i Navigator) and execute
the same CPYF *NOCHK against this table.
The copy will be stopped and the invalid data/record is not inserted.
*

Mit freundlichen Grüßen / Best regards

Birgitta Hauser

"Shoot for the moon, even if you miss, you'll land among the stars." (Les
Brown)
"If you think education is expensive, try ignorance." (Derek Bok)
"What is worse than training your staff and losing them? Not training them
and keeping them!"

-----Ursprüngliche Nachricht-----
Von: MIDRANGE-L [mailto:midrange-l-bounces@xxxxxxxxxxxx] Im Auftrag von Jon
Paris
Gesendet: Friday, 24.10 2014 20:44
An: Midrange-L Midrange-l
Betreff: Re: Can I use DDS to create an SQL table name

I?ve never understood the ?validation on read? claim. There is no
validation - if there was you would never get a decimal data error on the
field move that follows the basic read/chain. It would be stopped back at
the DB level.

The new query engine now works on just about all tables right? So there?s no
specific advantage there.

I?m with you Vern - there?s a lot of reason to use SQL. Far less to switch
to DDL.


Jon Paris

www.partner400.com
www.SystemiDeveloper.com

On Oct 24, 2014, at 2:35 PM, Vernon Hamberg <vhamberg@xxxxxxxxxxxxxxx>
wrote:

I too have been thinking that I've not seen enough performance testing to
justify the claims - they all feel pretty theoretical right now. Lots of "it
depends".

The new query engine - yes, that clearly has advantages for many queries.

But faster reads because there is no validation there? Probably no big
deal for interactive work - long batch stuff, maybe.

I'm all for the new capabilities in SQL - and the DML can work against
both DDS-based files and DDL-based tables. At this time I'm inclined to say
that the benefits are more in using SQL as a language, not so much in
creating database objects.

OK, bring on the firearms, y'all - I'm fully protected!! I've survived
conversations in LinkedIn groups! And left!

Vern

On 10/24/2014 12:44 PM, rob@xxxxxxxxx wrote:
I think that the vastly improved data integrity and security of DDL
should be a much bigger factor than the improved key indexing. Chuck
has a point that he really wants to see the cold hard performance
comparisons.


Rob Berendt
-- IBM Certified System Administrator - IBM i 6.1 Group Dekko Dept 1600
Mail to: 2505 Dekko Drive Garrett, IN 46738 Ship to: Dock 108 6928N 400E
Kendallville, IN 46755 http://www.dekko.com From: Mike Cunningham
<mike.cunningham@xxxxxxx> To: Midrange Systems Technical Discussion
<midrange-l@xxxxxxxxxxxx> Date: 10/24/2014 01:18 PM Subject: RE: Can I use
DDS to create an SQL table name Sent by: "MIDRANGE-L"
<midrange-l-bounces@xxxxxxxxxxxx> Chuck, what about access to the improved
key indexing that an SQL defined table gives you? 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. -----Original Message----- From:
MIDRANGE-L [mailto:midrange-l-bounces@xxxxxxxxxxxx] On Behalf Of CRPence
Sent: Friday, October 24, 2014 1:03 PM To: midrange-l@xxxxxxxxxxxx Subject:
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 close d 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.

--
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 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.



As an Amazon Associate we earn from qualifying purchases.

This thread ...

Follow-Ups:
Replies:

Follow On AppleNews
Return to Archive home page | Return to MIDRANGE.COM home page

This mailing list archive is Copyright 1997-2024 by midrange.com and David Gibbs as a compilation work. Use of the archive is restricted to research of a business or technical nature. Any other uses are prohibited. Full details are available on our policy page. If you have questions about this, please contact [javascript protected email address].

Operating expenses for this site are earned using the Amazon Associate program and Google Adsense.