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




 If you reorganize the physical files you have the ability to put the
records in the same physical order as the keys.  The records in a file are
physically written in the order they arrive at the file.  This is called
Arrival Sequence which usually is very different from the order of the key
field(s). Reorganizing the file will rewrite the file in the order of the
key(s) selected, so that Arrival Sequence and Key Sequence are identical.
Later additions to the file will be added at the end until the next
reorganize.

Is there some real reason the records must be processed in Key Sequence
instead of Arrival Sequence? (Just because a file is keyed does not mean you
must process it in key order.)  You are processing 100% of them anyway,
right?  Why would you care what order they are processed, so long as all of
them are completed?  The difference in performance time can be astounding.
Be really sure there is a valid reason for the K.

I've never tried the following for performance but could you
program-describe the file with a record length of 3768, with Field3768 of
3768 length?  Then 6 DataStructures EXTNAMEd for your 6 formats, and a

SELECT
WHEN %SubST(Field3768:__:__) = '??a'
Eval DataStructureA = Field3768
WHEN %SubST(Field3768:__:__) = '??b'
Eval DataStructureB = Field3768
WHEN %SubST(Field3768:__:__) = '??c'
Eval DataStructureC = Field3768
WHEN %SubST(Field3768:__:__) = '??d'
Eval DataStructureD = Field3768
WHEN %SubST(Field3768:__:__) = '??e'
Eval DataStructureE = Field3768
WHEN %SubST(Field3768:__:__) = '??f'
Eval DataStructureF = Field3768
EndSL

This method gets rid of the multi-format Logical and may reap big
performance leaps.

---------------------------------------------------------
Booth Martin   http://www.MartinVT.com
Booth@MartinVT.com
---------------------------------------------------------

-------Original Message-------

From: rpg400-l@midrange.com
Date: Wednesday, December 25, 2002 02:45:34
To: rpg400-l@midrange.com
Subject: Re: NBRRCDS and BLOCK(*YES)

thanks to all of you who responded and gave a valuable feedback.

1) Yes my intention is to improve performance
2) I am using a 'Multi format Logical File' having 3 million records and
record length is 3768 (sorry its not a join logical) with 6 record foramats
from 6 files
The file is declared as a 'Primary and Update' file and update operations
are being performed.
3) The key of the multi format logical file is a single field PNO and is
same as the physical files in 4 cases. In 2 other case, the physical file
has one more field in the key apart from having PNO as the first field in
the key
4) I am not able to take out the K as the file is keyed
5) Since the file is in update mode, block(*yes) is not helpful
6) Original program was called froma CL using an OVRDBF on this file with
NBRRCDS as 3
7) I tried increasing 3 to 100 and observed performance gain (tested for
1300 records and observered performance gain from 3 minutes 40 seconds to 1
minute 3 seconds)

8) Now my worry is, where ever I refer to NBRRCDS details it mentions that
" if the file is processed by a keyed order, then the physical order of
data should be same as the keyed order else NBRRCDS will worse the
performance"
a) How do I know what is the physial order of data. (I dont understand
this)
b) How to find out what should be the value of NBRRCDS, if the physical
order of data (that I find after receiving feedback from you all) is the
same as the keyed order.

thanking you in advance.
Wish you all a Merry Christmas






"Booth Martin" <Booth@MartinVT.com&gt;@midrange.com on 12/23/2002 10:12:16
PM

Please respond to rpg400-l@midrange.com

Sent by: rpg400-l-admin@midrange.com


To: <rpg400-l@midrange.com>
cc:

Subject: Re: NBRRCDS and BLOCK(*YES)

NBRRCDS(3)?? a very small file?

What is it you are looking for? Performance improvements? Have you taken
out the K?

My experience with Block(*yes) was a revelation. It provided close to 70%
reduction in processing time in two different applications. I was
astounded




---------------------------------------------------------
Booth Martin http://www.MartinVT.com
Booth@MartinVT.com
---------------------------------------------------------

-------Original Message-------

From: rpg400-l@midrange.com
Date: Monday, December 23, 2002 06:58:54
To: rpg400-l@midrange.com
Subject: NBRRCDS and BLOCK(*YES)

Hello Everybody,

Can anyone clarify me regarding:

My programs uses a file in update and primary mode. The file is a join
logical file. All records being read in processed and updated.
Record length is 3768

"1) Can I specify NBRRCDS or BLOCK(*yes)
2) If I specify NBRRCDS(3) in OVRDBF and specify BLOCK(*yes) in F specs for
the same file, which will be effective ?
3) Which one is beneficial.

thank you in advance

_______________________________________________
This is the RPG programming on the AS400 / iSeries (RPG400-L) mailing list
To post a message email: RPG400-L@midrange.com
To subscribe, unsubscribe, or change list options,
visit: http://lists.midrange.com/cgi-bin/listinfo/rpg400-l
or email: RPG400-L-request@midrange.com
Before posting, please take a moment to review the archives
at http://archive.midrange.com/rpg400-l.



_______________________________________________
This is the RPG programming on the AS400 / iSeries (RPG400-L) mailing list
To post a message email: RPG400-L@midrange.com
To subscribe, unsubscribe, or change list options,
visit: http://lists.midrange.com/cgi-bin/listinfo/rpg400-l
or email: RPG400-L-request@midrange.com
Before posting, please take a moment to review the archives
at http://archive.midrange.com/rpg400-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.