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



And of course larger block sizes are not always an advantage. They can result in wasted I/O time bringing in stuff that will be discarded.

Like Vern I have always felt that the fact that we can use RLA _and_ SQL against our data is a major advantage that we should shout from the rooftops. There are occasions when RLA is the right tool for the job but the data also needs set style access. Other systems force you to make a decision one way or the other with resulting inefficiencies - we don't have to do that.


Jon Paris

www.partner400.com
www.SystemiDeveloper.com

On Jan 14, 2017, at 2:29 PM, Vernon Hamberg <vhamberg@xxxxxxxxxxxxxxx> wrote:

Bad practice? Technically? I think not - the underlying structure tables and files is the same - just do a DMPOBJ of an example of both, and it is obvious. The underlying MI object types are the same - *FILE, *FMT, *MEM (member), *QDDS.

Here are a couple examples of DMPOBJ output of a file and a table that are otherwise the same -

OBJECT TYPE- SPACE *FILE
NAME- TESTPFDDS TYPE- 19 SUBTYPE- 01
OBJECT TYPE- SPACE *FMT
NAME- TESTPFDDSR TYPE- 19 SUBTYPE- 51
OBJECT TYPE- CURSOR *MEM
NAME- TESTPFDDS TESTPFDDS TYPE- 0D SUBTYPE- 50
OBJECT TYPE- DATA SPACE *QDDS
NAME- TESTPFDDS TESTPFDDS TYPE- 0B SUBTYPE- 90

OBJECT TYPE- SPACE *FILE
NAME- TESTPFDDL TYPE- 19 SUBTYPE- 01
OBJECT TYPE- SPACE *FMT
NAME- TESTPFDDL TYPE- 19 SUBTYPE- 51
OBJECT TYPE- CURSOR *MEM
NAME- TESTPFDDL TESTPFDDL TYPE- 0D SUBTYPE- 50
OBJECT TYPE- DATA SPACE *QDDS
NAME- TESTPFDDL TESTPFDDL TYPE- 0B SUBTYPE- 90

There will be some values in the first few rows of the dump, which hold the object-based attributes that distinguish them.

Or just do a DSPFD - the main section at the beginning will have almost everything the same - one difference is SQL attributes in the DDL-based objects.

So I feel that advice that DDL-based objects with RLA is bad - that is more of a religious argument - yes, there are are possible performance advantages due to larger block sizes in indexes, but that, for me, means that using an index with native IO is even better than using an LF. It's more of taking a position to move to SQL only - and that doesn't have technical merit, so much as it might have merit as to aligning with what is done if you work with another RDBMS.

Regards
Vern

On 1/14/2017 11:43 AM, D*B wrote:
SQL and RLA compliment one another rather than compete.

creating tables with SQL DDL and using RLA, as some experts recommend, is a bad practice, you are falling bacl behind DDS defined join files. tumbling around in the database to grab together data, a join operation would deliver easily. Another weakness of RLA is: the tight coupling from database implementation and application.
-snip-
--
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.

Please contact support@xxxxxxxxxxxx for any subscription related questions.

Help support midrange.com by shopping at amazon.com with our affiliate link: http://amzn.to/2dEadiD


As an Amazon Associate we earn from qualifying purchases.

This thread ...

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.