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



I would take this one step further:  *Any* SETLL/READE that is using the
*exact same key/klist* is identical to a CHAIN.  (At least in times past,
(but could-a changed,) the I/O count shows 2 I/Os for the former and 1 for
the latter.  Yeah, with caching that may not mean much, but there *are*
occasions when there's a biz/tech requirement for a SETLL by a partial key
and then a READE by a *different* key.  Ime (in my experience) these cases
should *boldly stand out*, plus the CHAIN gives simpler code (and I've
expressed my reservations on ITER previously):

C     myklist       chain     myfile                    50
C                   doW       not *In50
C***  do whatever processing needed here
C                   eval      rrn = rrn + 1
C                   write     mysubfile
C
C     myklist       reade     myfile                        50
C                   enddo

(The only reason I use a throw-away indicator is I'm not Freudian about
indicators and the rules of %eof have changed and aren't part of "the back
of my hand".  Besides, if you can't wrap your head around the concept of a
bit, then you're in the wrong biz.)

Furthermore, I am NOT one to spend time trying to get down to a minimum
number of lines of code just for the principle of it.  But a simpler design
DOES have greater extensibility:

You can replace Chain/Reade with Read's, and you've re-invented the primary
file.
You can replace myfile with a SFL, and myklist with RRN
You can do same, but use READC to process a SFL
If you only want FIRST record of a given key, you can add a SETGT prior to
READE by a different key
..etc, etc, ime anyway...

Well, just saw John Brandt's post come in after I wrote all the above...;-D
Make a long story short (oops) I agree with John.


| -----Original Message-----
| [mailto:rpg400-l-bounces@xxxxxxxxxxxx]On Behalf Of Marvin Radding
| Sent: Friday, March 26, 2004 10:58 AM

| While there is nothing wrong with your code, I think this way is more
| effiecient.
|
| C     myklist       setll     myfile
| C
| C                   dou       %eof(myfile)
| C
| C     myklist       reade     myfile
| C                   if        %eof(myfile)
| C                   iter
| C                   endif
| C
| C                   eval      rrn = rrn + 1
| C                   write     mysubfile
| C
| C                   enddo
|
| Marvin Radding
|
|
| message: 1
| date: Thu, 25 Mar 2004 14:32:35 -0800 (PST)
| from: simafrog <SimaFrog@xxxxxxxxxx>
| subject: SETLL ONE SLIGHT PROBLEM
|
| Actually I don't think I can do this here anyway. One problem remaining
| is that the reade of the Detail file is causing one extra record to be
| added to the work file, the last one of the batch is duplicated. Here is
| the code:
|  C           BLD       BEGSR
|  C*
|  C           OHKEY     SETLLORDHEDR             40
|  C*
|  C           *IN40     DOWEQ*OFF
|  C*
|
|  C           OHKEY     READEORDHEDR                 40
|  C           *IN40     IFEQ '0'
|  C*
|  C           C*
|  C           ODKEY     SETLLORDDTL                   50
|  C           *IN50     DOUEQ*ON
|  C           ODKEY     READEORDDTL                   50
|  C                     WRITEORDSWRKF
|  C                     END
|  C                     END
|  C                     END
|  C*
|  C                     ENDSR




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.