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




Hi James
I have no idea why this is happening, however, the following may be a
solution (if that's what you are looking for)
Define the input file with usropn and open the file instead of using setll

like
FHPADLPUA IF F 1243 DISK USROPN
D RECORD DS 1243
C IF %OPEN(HPADLPUA)
C CLOSE HPADLPUA
C ENDIF
C OPEN HPADLPUA
C READ HPADLPUA RECORD

I believe that will start to at the beginning of the file (via rrn)


Alan Shore
Programmer/Analyst, Direct Response
E:AShore@xxxxxxxx
P:(631) 200-5019
C:(631) 880-8640
"If you're going through Hell, keep going" - Winston Churchill

Alan Shore
Programmer/Analyst, Direct Response
E:AShore@xxxxxxxx
P:(631) 200-5019
C:(631) 880-8640
"If you're going through Hell, keep going" - Winston Churchill



"James H. H.
Lampert"
<jamesl@touchtone To
corp.com> RPG programming on the IBM i /
Sent by: System i <rpg400-l@xxxxxxxxxxxx>
rpg400-l-bounces@ cc
midrange.com
Subject
Failed SETLL leaving program at
03/18/2010 02:34 undefined position in SQL VIEW, but
PM not in DDS LF


Please respond to
RPG programming
on the IBM i /
System i
<rpg400-l@midrang
e.com>






This is really about an MI program (see the thread on the MI list), but
it also happens in an RPG test program that approximates the
point-of-failure in the MI, so maybe somebody who's here, but not on the
MI list might have an insight.

It seems that with this code (intentionally opening the file in
program-described mode, as that's essentially what happens in the
original MI program):

FHPADLPUA IF F 1243 DISK
D RECORD DS 1243
C 1 SETLL HPADLPUA 121314
C READ HPADLPUA RECORD

if I run it on a DDS LF, and RRN 1 is omitted by a SELECT clause in the
DDS, the SETLL comes back with an error, but the READ still finds the
first record that satisfies the SELECT.

But if I run an otherwise identical program on an equivalent SQL VIEW of
the same data, the READ fails, evidently from the file being left at an
undefined position.

SETGT (and this surprised me) also returned with an error, and left the
SQL VIEW at an undefined position.

Anybody know of a way, short of iteratively SETLLing until a record is
found, to deal with this?

--
JHHL
--
This is the RPG programming on the IBM i / System i (RPG400-L) mailing list
To post a message email: RPG400-L@xxxxxxxxxxxx
To subscribe, unsubscribe, or change list options,
visit: http://lists.midrange.com/mailman/listinfo/rpg400-l
or email: RPG400-L-request@xxxxxxxxxxxx
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.