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



Vern,

I agree that at V5R4, a select/omit LF is the only way to get a keyed, sorted LF with selection in one object. But it isn't the only solution.

As I stated earlier, if the option is availble to modify the native I/O code, then a single index, with NCSTAT & NCNPROD would be my preferred solution. This gives greater flexibilty and better performance than indexes and views combined.

So, code that performed

Chain ( ITEM ) NSCHGRQFL1 (which is keyed and has NCSTAT = 'D')

would be replaced with

Chain ( 'D' : ITEM ) NSCHGRQFL1 (which is keyed and has the desired selection)

I also find this easier to read and understand than embedding (hiding) select/omit criteria in a LF (or within a View).

Cheers,
Sean



________________________________

From: midrange-l-bounces@xxxxxxxxxxxx on behalf of Vern Hamberg
Sent: Mon 15/03/2010 18:55
To: Midrange Systems Technical Discussion
Subject: Re: DDL Record Select



Sean

Dave wants a keyed, sorted LF with selection - that is a select/omit LF
and is the only way to get all that in one object.

Now that object is not very well-suited to SQL. For SQL he should have
both an view and an index or 2.

The view would have the selection criteria in a WHERE clause.

One index would support the view's selectivitiy. The other would do the
sort. Now it might be possible to have both in one index - all the
better. Depends on what those criteria are relative to the ordering.

With that, SQL can do very well. And RPG can use both a view and and
index. However, there will be no builtin ordering with the view if used
in an F-spec and no selectivity with the index (until 6.1) if used in an
F-spec.

If he means to use the LF only in native RPG IO, then the select/omit is
probably the best answer.

Later
Vern

McGovern, Sean wrote:
If you are at V5R4 and want a logical file that performs record
selection, and want to use DDL, you will need to use a view.

But what happens when you want to select records with NCSTAT with a
value other than 'D' ? You will need another view.

The best approach, IMO, is to create 1 index with both NCSTAT and
NCNPROD defined.



-----Original Message-----
From: midrange-l-bounces@xxxxxxxxxxxx
[mailto:midrange-l-bounces@xxxxxxxxxxxx] On Behalf Of
daparnin@xxxxxxxxxxxxxx
Sent: 15 March 2010 14:37
To: Midrange Systems Technical Discussion
Subject: RE: DDL Record Select

Thanks to all for the responses. We are at V5R4 so I will probably have

to investigate the difference between an index and a view. The end
result
that I want is a keyed, sorted logical file that does record selection.
I'm trying to "modernize" my approach to such things but I'm still
getting
up to speed. Rob mentioned the record format. I've been creating the
file with the record format name and then renaming it to the real file
name so the record format stays with what I want it to be. I was
thinking
that the ability to specify a record format name was a V6R1 thing. As
for
why we're not on V6R1, it basically hasn't bubbled up on the priority
list
for those allocating the resources.



Dave Parnin

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

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.